Um método de integração de dados armazenados em - INF

U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
F LÁVIO DE A SSIS V ILELA
Um método de integração de dados
armazenados em bancos de dados
relacionais e NOSQL
Goiânia
2015
F LÁVIO DE A SSIS V ILELA
Um método de integração de dados
armazenados em bancos de dados
relacionais e NOSQL
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Computação.
Área de concentração: Ciência da Computação.
Orientador: Prof. Dr. João Carlos da Silva
Co-Orientador: Prof. Dr. Fábio Nogueira de Lucena
Goiânia
2015
F LÁVIO DE A SSIS V ILELA
Um método de integração de dados
armazenados em bancos de dados
relacionais e NOSQL
Dissertação defendida no Programa de Pós–Graduação do Instituto de
Informática da Universidade Federal de Goiás como requisito parcial
para obtenção do título de Mestre em Computação, aprovada em
07 de Setembro de 2015, pela Banca Examinadora constituída pelos
professores:
Prof. Dr. João Carlos da Silva
Instituto de Informática – UFG
Presidente da Banca
Prof. Dr. Fábio Nogueira de Lucena
Instituto de Informática – UFG
Prof. Dr. Leonardo Andrade Ribeiro
Universidade Federal de Goiás – UFG
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho sem autorização da universidade, do autor e do orientador(a).
Flávio de Assis Vilela
Graduado em Sistemas de Informação pelo Instituto Federal de Goiás - Campus Jataí. Possui o título de Especialista em Desenvolvimento de Software
pela instituição Senac. Atualmente é professor no Instituto Federal de Goiás Campus Jataí e analista de sistemas na empresa FAV Sistemas, em Jataí - GO.
À minha irmã Larissa.
Agradecimentos
Primeiramente, agradeço aos meus pais por sempre acreditarem em mim, que,
apesar de todas as nossas dificuldades (psicológicas, familiares e financeiras), me apoiaram em todas as decisões e sempre me incentivaram a buscar novos conhecimentos,
motivo pelo qual me fez ingressar no mestrado.
Agradeço imensamente ao professor Dr. João Carlos que, primeiramente, me
aceitou como seu orientando, e, desde então, foi a pessoa que mais contribuiu na minha
formação acadêmica, intelectual e pessoal. Agradeço pelos conhecimentos em Banco de
Dados com ele adquiridos, pela disponibilidade, pela paciência e pela confiança em mim
depositado.
Agradeço ao professor Dr. Fábio Nogueira de Lucena que desempenhou um
papel importante para a conclusão deste trabalho. Em todo o momento, não mediu
esforços para me atender, sempre com novas idéias para melhorar o trabalho e me
ajudando imensamente em dúvidas referentes à implementação. Agradeço ainda pela
paciência na correção dos trabalhos escritos e pelas sugestões propostas.
Aos colegas de mestrado que muitas vezes dedicaram seu tempo para me ajudar,
em especial à Mariana, que nunca se absteve em me ajudar, principalmente na etapa da
escrita do texto. Aos colegas de disciplinas que fiz durante o mestrado, especialmente a
Walquiria e ao Cleon, pessoas que estiveram ao meu lado durante todo este longo percurso
e, com nossas afinidades, nos fizemos amigos.
Não há lugar para expressar o sentimento que sinto (ódio, raiva, impunidade),
mas acredito que aqui seja um local oportuno e que ficará registrado para todos que fizer
a leitura deste trabalho. Agradeço a você, minha irmã Larissa, por sempre ter sido uma
pessoa dedicada nos estudos e melhor a cada dia, motivo que me faz espelhar em você.
Uma pena que Deus não deixou você defender seu mestrado, e, dias antes, te chamou pra
morar com Ele. Ah, quanto ao sentimento que sinto, sim, é saudade, imensa saudade.
Resumo
de Assis Vilela, Flávio. Um método de integração de dados armazenados em
bancos de dados relacionais e NOSQL. Goiânia, 2015. 98p. Dissertação de
Mestrado. Instituto de Informática, Universidade Federal de Goiás.
O aumento da quantidade e variedade de dados disponíveis na Web contribuiu com o surgimento da abordagem NOSQL, visando atender novas demandas, como disponibilidade,
flexibilidade de esquema e escalabilidade. Paralelamente, bancos de dados relacionais são
largamente utilizados para armazenamento e manipulação de dados estruturados, oferecendo estabilidade e integridade de dados, que são acessados através de uma linguagem
padrão, como SQL. Este trabalho apresenta um método de integração de dados armazenados em fontes heterogêneas, no qual uma consulta de entrada em SQL produz uma resposta unificada, baseada nas respostas parciais de bancos de dados relacionais e NOSQL.
Palavras–chave
Integração de dados, Banco de dados relacional, Banco de dados NOSQL.
Abstract
de Assis Vilela, Flávio. . Goiânia, 2015. 98p. MSc. Dissertation. Instituto de
Informática, Universidade Federal de Goiás.
The increase in quantity and variety of data available on the Web contributed to the
emergence of NOSQL approach, aiming at new demands, such as availability, schema
flexibility and scalability. At the same time, relational databases are widely used for
storing and manipulating structured data, providing stability and integrity of data, which
is accessed through a standard language such as SQL. This work presents a method for
integrating data stored in heterogeneous sources, in which an input query in standard
SQL produces a unified answer, based in the partial answers of relational and NOSQL
databases.
Keywords
Data integration, relational database, NoSQL Database.
Sumário
Lista de Figuras
10
Lista de Tabelas
12
1
Introdução
1.1
1.2
1.3
1.4
1.5
1.6
2
Trabalhos Relacionados
2.1
2.2
3
Integração de dados entre bancos de dados relacionais e NOSQL
Integração de dados entre bancos de dados relacionais e outras fontes de dados
Fundamentação teórica
3.1
3.2
3.3
3.4
3.5
4
Contextualização
Objetivos
Principais necessidades
Desafios encontrados
Restrições do método proposto
Organização do texto
Modelo relacional
Abordagem NOSQL
3.2.1
Modelo de dados
3.2.2
Categorias de bancos de dados NOSQL
3.2.3
Outras características da abordagem NOSQL
Dados estruturados e não estruturados
Metadados
Arquitetura JDBC
3.5.1
Driver JDBC para Cassandra
3.5.2
Driver JDBC para MongoDB
Um método para integração de dados armazenados em bancos de dados
relacionais e NOSQL
4.1
4.2
Modelo da solução proposta
Estrutura do método
4.2.1
Consulta SQL Inicial
4.2.2
Depósitos de dados
Elementos SQL
Metadados
Fontes de Dados
Resultados
4.2.3
Analisar Consulta SQL
1
1
3
4
4
5
6
7
7
9
18
18
20
21
21
28
30
32
33
35
36
37
37
38
38
39
40
41
44
44
44
5
4.2.4
Construir Comandos SQL
4.2.5
Controlar Execução de Consultas SQL
4.2.6
Gerenciar Resultados
4.2.7
Exemplo passo a passo
Um protótipo para avaliar o método de integração de dados
5.1
5.2
5.3
5.4
Desafios encontrados durante o desenvolvimento
Requisitos do protótipo
Descrição do protótipo
5.3.1
Tecnologias utilizadas
5.3.2
Funcionalidades do protótipo
Resultados obtidos
5.4.1
Ambiente dos experimentos
5.4.2
Exemplos de consultas
Consultas envolvendo apenas bancos de dados relacionais
Consultas envolvendo apenas bancos de dados NOSQL
Consultas envolvendo bancos de dados relacionais e bancos de dados NOSQL
5.5
6
Conclusão
6.1
6.2
A
Considerações Finais
Contribuições
Trabalhos Futuros
Dados para executar os experimentos
Referências Bibliográficas
46
48
49
50
53
53
54
55
55
55
58
59
66
67
68
74
78
80
81
81
83
94
Lista de Figuras
2.1
2.2
2.3
Middleware de integração de dados criado em [45]
Estrutura do método criado em [4].
Estrutura do método desenvolvido em [10].
8
12
13
3.1
3.2
3.3
3.4
3.5
Tipos de dados gerados nos últimos anos [39].
Estrutura do banco de dados chave-valor
Estrutura do banco de dados MongoDB [43]
Exemplo da estrutura de armazenamento do MongoDB
Comparação da sintaxe de criação de uma relação em banco de dados
relacional e MongoDB [22]
Comparação da sintaxe de inserção de dados em banco de dados relacional e MongoDB [22]
Comparação da sintaxe de consulta em banco de dados relacional e
MongoDB [22]
Estrutura de armazenamento do banco de dados Cassandra
Exemplo da sintaxe de criação de relações CQL [7]
Teorema CAP [42]
Exemplo de dados não estruturados
Tipos de drivers JDBC [46]
Exemplo da arquitetura JDBC [44]
19
22
22
23
Fluxo de dados do método proposto
Exemplo de consulta
Relações do depósito Elementos SQL
Outras relações do depósito Elementos SQL
Representação das relações que compõe os metadados
Estrutura de um banco de dados orientado a colunas mapeada para o
modelo relacional
4.7 Estrutura de um banco de dados orientado a documentos mapeada para
o modelo relacional
4.8 Exemplo de consulta SQL de entrada redefinida
4.9 Elementos SQL após a análise da consulta SQL
4.10 Consultas construídas pelo método.
4.11 Consulta inicial executada no depósito Resultados
39
39
40
41
42
5.1
5.2
5.3
5.4
55
56
57
57
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
4.1
4.2
4.3
4.4
4.5
4.6
Tela inicial do protótipo
Tela de cadastro metadados de conexão
Tela de cadastro de relações
Tela de cadastro de atributos
24
24
25
26
27
28
31
33
35
43
44
45
46
48
50
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
5.29
5.30
5.31
5.32
5.33
5.34
5.35
Tela de cadastro de domínios
Famílias de colunas criadas no banco de dados Cassandra.
Coleção de documentos Clientes criada no banco de dados MongoDB.
Coleção de documentos Fornecedor criada no banco de dados MongoDB.
Coleção de documentos CondPag criada no banco de dados MongoDB.
Relações criadas no banco de dados MSSQL Server.
Relação Funcionarios criada no banco de dados Postgresql.
Relações utilizadas no experimento
Ambiente dos experimentos
Exemplo - Consulta 1
Resultado da Consulta 1
Exemplo - Consulta 2
Resultado da Consulta 2
Exemplo - Consulta 3
Resultado da Consulta 3
Exemplo - Consulta 4
Resultado da Consulta 4
Exemplo - Consulta 5
Resultado da Consulta 5
Exemplo - Consulta 6
Resultado da Consulta 6
Exemplo - Consulta 7
Resultado da Consulta 7
Exemplo - Consulta 8
Resultado da Consulta 8
Exemplo - Consulta 9
Resultado da Consulta 9
Exemplo - Consulta 10
Resultado da Consulta 10
Exemplo - Consulta 11
Resultado da Consulta 11
58
60
61
61
62
63
64
64
66
67
67
68
68
69
69
70
70
71
71
72
72
73
73
74
74
75
75
76
76
77
77
Lista de Tabelas
2.1
2.2
3.1
Mapeamento da estrutura de um banco de dados relacional para o banco
de dados SimpleDB [4].
Características dos trabalhos relacionados
11
16
3.4
3.5
Comparação dos termos utilizados em bancos de dados relacionais e
MongoDB [22]
Exemplos de consultas utilizando o CQL [7]
Comparação do tempo de inserção entre bancos de dados NOSQL e
relacional [19]
Exemplo de dados estruturados
Exemplo de metadados
4.1
4.2
4.3
4.4
4.5
4.6
Relações, atributos e predicados da relação Vendas.
Relações, atributos e predicados da relação Cliente.
Consultas SQL construídas para cada relação.
Relação Cliente criada no depósito Resultados.
Relação Vendas criada no depósito Resultados.
Resultado da consulta inicial executada no depósito Resultados.
50
51
51
51
51
52
5.1
5.2
5.3
5.4
Tabela de requisitos funcionais do protótipo
Tabela de requisitos não funcionais do protótipo
Configuração dos metadados de conexão no depósito Metadados
Conjunto de relações, coleções de documentos e famílias de colunas para
os experimentos.
54
54
59
Dados armazenados na coleção de documentos Clientes
Dados armazenados na coleção de documentos CondPag
Dados armazenados na coleção de documentos Fornecedor
Dados armazenados na família de colunas vendas
Dados armazenados na família de colunas ItensVendas
Dados armazenados na relação Produto
Dados armazenados na relação Funcionarios
Dados armazenados na relação EntradaNFe
Dados armazenados na relação ItensEntrada
83
84
84
85
89
89
90
90
93
3.2
3.3
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
23
27
29
31
32
60
CAPÍTULO 1
Introdução
Este capítulo contextualiza o tema deste trabalho, a motivação, os objetivos e
desafios encontrados. A seção 1.1 apresenta a contextualização. A seção 1.2 discute os
objetivos do trabalho. A seção 1.3 apresenta as principais necessidades identificadas
durante a pesquisa. A seção 1.4 descreve as motivações para realização deste trabalho.
A seção 1.5 discute os desafios encontrados durante a pesquisa. A seção 1.6 apresenta
as restrições para o método proposto. E por fim, a seção 1.7 apresenta a organização do
texto.
1.1
Contextualização
Os mecanismos de busca utilizados na Web (World Wide Web) tornaram-se uma
importante alternativa para as pessoas encontrarem diversas informações que necessitam,
desde a busca por uma letra de música, amigos em redes sociais, até uma pesquisa
bibliográfica para uma tese de doutorado. Um usuário pode obter resultados de consultas
em diversos formatos, tais como tabelas, texto, páginas da Web, fotos e outros. Rout et
al. [32] comentam sobre a quantidade de dados disponíveis na Web. De acordo com as
pesquisas, a quantidade de dados estão na esfera de petabytes ou exabytes, que consiste
em trilhões de registros de milhões de usuários. Todos estes dados são originados de
páginas daWeb, dados de vendas de produtos, dados de dispositivos móveis e outros.
Os dados manipulados em aplicações podem estar na forma estruturada, que é
um tipo de dado com a mesma estrutura, armazenados em um repositório com modelo de
dados definido e permitindo relacionamentos [28]. Por outro lado, também podem estar na
forma não estruturada [35], [12], [41], que são dados contidos em arquivos como vídeos,
fotos, documentos de texto, páginas da Web, e para os quais não há uma definição do
modelo e da estrutura de armazenamento [12].
Durante anos, os bancos de dados relacionais foram utilizados como solução no
armazenamento de dados em diferentes cenários [17], em que uma das características
principais é o uso da linguagem SQL para interagir com os banco de dados. Hecht e
Jablonski [14] argumentam que, mesmo não sendo indicado em alguns contextos, bancos
1.1 Contextualização
2
de dados relacionais são utilizados para armazenar os diversos tipos de dados manipulados
pelas aplicações. Stonebraker et al. [37] argumentam que, inicialmente, os bancos de
dados relacionais foram arquitetados com as características de hardware diferentes às
atuais, além de serem desenvolvidos com base em processamento de dados de negócios.
Entretanto, nos últimos 25 anos, uma série de outras áreas evoluíram, por exemplo, data
warehouse. Esses mercados exigem necessidades diferentes às encontradas em dados
comerciais.
A abordagem NOSQL surgiu com a proposta de oferecer recursos diferentes no
armazenamento de dados, baseando-se nas características encontradas em ambientes Web
[45], no qual se encontra uma grande massa de dados, podendo apresentar diferentes formatos e serem acessados por vários usuários simultaneamente. Algumas características da
abordagem NOSQL são: esquema flexível, alta disponibilidade e escalabilidade horizontal [14], [13], [25]. Existem, no entanto, recursos importantes que não estão disponíveis
em bancos de dados NOSQL, como a linguagem de consulta SQL. Em vez disso, cada
banco de dados NOSQL oferece API própria para manipulação de dados [29].
Parker et al. [28] argumentam que os dados gerados em aplicações, mesmo sendo
dados estruturados, não são, obrigatoriamente, armazenados em bancos de dados relacionais. A utilização de bancos de dados dessa abordagem está associada com o ambiente
em que será implantada a aplicação, se haverá uma grande massa de dados sendo acessada simultaneamente, se haverá necessidade de executar consultas complexas com os
bancos de dados, entre outras características. Entretanto, os dados podem ser do tipo não
estruturado, e mesmo assim, não há relação em dizer que, obrigatoriamente, serão armazenados em bancos de dados NOSQL [28]. É possível armazenar dados estruturados em
bancos de dados NOSQL, no entanto, os bancos de dados dessa abordagem armazenam
os dados em um esquema flexível, podendo armazenar dados com diferentes formatos,
além de não fornecerem as propriedades ACID (atomicidade, consistência, isolamento e
durabilidade), o que proporciona melhor desempenho no acesso e manipulação dos dados
[28].
Com um volume cada vez maior de dados disponíveis através da rede mundial,
surgem cenários em que os dados de uma mesma aplicação estão distribuídos em diversas
fontes de dados [38], especificamente em bancos de dados relacionais ou bancos de
dados NOSQL. Zhang et al. [45] apontam um exemplo em que uma aplicação consome
informações de bases relacionais e NOSQL. Parte dos dados pode conter uma estrutura
definida, sobre os quais pode ser necessário realizar consultas com maior complexidade
e precisão, garantir a consistência e integridade dos dados [45], [18]. Neste contexto,
a utilização de bancos de dados relacionais é recomendada. No entanto, uma grande
massa de dados pode estar disponível para ser acessada por usuários simultaneamente,
e, neste caso, podem ser parcialmente irrelevantes aspectos de consistência, integridade,
1.2 Objetivos
3
durabilidade dos dados, e mais importante um menor tempo de consulta, disponibilidade
da aplicação e flexibilidade no armazenamento dos dados [25], [19], [28], [14], [17].
Nesses cenários, a utilização de um banco de dados NOSQL é recomendada.
No cenário citado em Zhang et al. [45], pode ser necessário submeter uma
consulta, requisitando dados distribuídos em bancos de dados relacionais e NOSQL,
e ainda, os bancos de dados podem estar distribuídos geograficamente entre várias
organizações ou até mesmo em várias cidades [41].
Neste contexto, este trabalho apresenta um método capaz de consultar dados
armazenados em bancos de dados relacionais e NOSQL, através de uma única consulta
escrita no padrão da linguagem de consulta SQL, e apresentar o resultado de forma
unificada. Em busca de criar um mecanismo único de acesso aos dados, considerando que
os bancos de dados NOSQL não apresentam um padrão de linguagem de consulta, e para
viabilizar o uso da linguagem SQL como padrão de consulta, todos os bancos de dados
disponíveis são descritos por um conjunto previamente estabelecido de metadados, e, para
todos os bancos de dados, deve ser disponível um driver JDBC. Os bancos de dados
NOSQL são representados na forma de relações e atributos, à semelhança da abordagem
relacional.
De acordo com [26], atualmente estão disponíveis aproximadamente 150 bancos
de dados NOSQL, que compartilham algumas características semelhantes, porém oferecem muitos recursos diferentes. O presente trabalho não apresenta um método geral,
que envolva todos os bancos de dados NOSQL existentes, mas se restringe ao estudo de
bancos de dados NOSQL das categorias orientada a colunas e documentos. A categoria
orientada a colunas se deve ao fato de sua estrutura de armazenamento ser comparada a
bancos de dados relacionais, armazenando os dados em uma estrutura composta de linhas
e colunas. A categoria orientada a documentos se justifica por armazenar os dados em
uma estrutura diferente à orientada a colunas e relacionais, o que torna possível avaliar o
método utilizando outras estruturas de armazenamento NOSQL.
1.2
Objetivos
Considerando um ambiente contendo dados armazenados em bancos de dados
relacionais e NOSQL, o primeiro objetivo deste trabalho é apresentar um método capaz
de permitir que vários bancos de dados de diferentes abordagens sejam acessados a partir
de uma única consulta escrita no padrão SQL e os resultados parciais obtidos em cada
banco de dados sejam mesclados e apresentados de forma unificada.
O segundo objetivo da pesquisa é a utilização dos recursos disponíveis em bancos
de dados relacionais e NOSQL por uma mesma aplicação. As duas abordagens de bancos
1.3 Principais necessidades
4
de dados oferecem maneiras diferentes de manipulação de dados, o que torna um desafio
a integração dessas duas abordagens na mesma aplicação.
O terceiro objetivo está associado ao estudo de uma nova abordagem de banco
de dados. A abordagem NOSQL, em comparação à abordagem relacional, é ainda pouca
estudada e fundamentada. Com a pesquisa direcionada para esta abordagem, é possível
contribuir com os estudos sobre NOSQL, podendo, ainda, identificar técnicas empregadas
para resolução de outros problemas referentes à integração de dados, além de suprir as
necessidades encontradas durante a pesquisa.
Os objetivos específicos do trabalho a fim de alcançar os objetivos gerais são:
•
•
•
•
1.3
Estudo dos bancos de dados NOSQL e suas formas de executar consultas.
Verificar a forma de acesso aos bancos de dados NOSQL.
Identificar um padrão de acesso a dados em bancos de dados relacionais e NOSQL.
Estudo de técnicas de integração de dados já existentes.
Principais necessidades
Zhang et al. [45] propôs um método com o qual é possível realizar a integração
de dados entre bancos de dados relacionais e NOSQL (essa integração é discutida no
Capítulo 2). Entretanto, algumas necessidades não abordadas naquele trabalho foram
encontradas, que são:
• Permitir executar consultas contendo elementos de agregação e consequentemente
o uso das cláusulas group by e having.
• Permitir executar consultas contendo junções.
• Permitir que os atributos da consulta sejam informados sem identificar a relação ao
qual pertence.
• Detalhar todo o processo do método de integração de dados para viabilizar a
reprodução do trabalho.
1.4
Desafios encontrados
Durante o desenvolvimento desta pesquisa, vários obstáculos e desafios foram
encontrados:
• O trabalho empregado como principal referência para o presente trabalho não define
claramente quais as técnicas desenvolvidas para alcançar o objetivo proposto.
• Não foram encontradas implementações que tratam do assunto de integração de
dados com as características abordadas nesta pesquisa.
1.5 Restrições do método proposto
5
• As implementações de bancos de dados NOSQL não fornecem um mecanismo
padrão de comunicação. Cada banco de dados oferece maneiras diferentes de acesso
aos dados, o que dificulta a criação de um mecanismo homogêneo de integração.
1.5
Restrições do método proposto
O método proposto neste trabalho permite implementar as necessidades estudadas nesta pesquisa, como a integração de dados armazenados em bancos de dados relacionais e NOSQL, utilização de junções, agregações e outros elementos, em consultas que
não são reconhecidas pela abordagem NOSQL, e apresenta, de forma detalhada, todos os
processos executados. No entanto, não tem a pretensão de resolver todos os problemas
e/ou necessidades existentes referentes à integração de dados. As restrições do método
proposto são apresentadas nessa seção.
• Normalmente, as consultas SQL são construídas contendo relações, atributos e
outros elementos disponíveis na linguagem de consulta SQL. Algumas palavraschaves são utilizadas nos comandos SQL, na cláusula select e na cláusula where,
a fim de obter resultados diferentes em comparação com uma consulta padrão
(consultas sem elementos de agregação e junção, por exemplo). Os elementos que
são reconhecidos pelo método são: group by, having, order by, join (e variações),
sum, count, max, min, avg, >, <, =, >=, <=, <>, and, or, in.
Os elementos citados anteriormente são fornecidos pela linguagem de consulta
SQL e, portanto, qualquer banco de dados que utilize esta linguagem de consulta
poderá fazer uso desses recursos. No entanto, alguns bancos de dados implementam
funções próprias para obtenção de resultados diferentes. Por exemplo: a função
top, que é implementada pelo banco de dados MSSQL Server, tem a função de
limitar a quantidade de registros que são retornados por uma consulta. No banco
de dados Postgresql, essa mesma tarefa é executada pela função limit. No banco de
dados Oracle, essa funcionalidade é representada pela função rownum. Portanto,
as especificidades de cada banco de dados não são contempladas pelo método
proposto.
• O método proposto não considera aspectos como: escalabilidade, desempenho,
grande massa de dados sendo manipulados por vários usuários simultaneamente
e outras características encontradas em ambientes que lidam com várias fontes de
dados.
1.6 Organização do texto
1.6
6
Organização do texto
Após este capítulo que apresentou a contextualização, a motivação, as necessidades identificadas durante a pesquisa e os objetivos da pesquisa, o trabalho contém ainda
outros 6 capítulos. O capítulo 2 discute os trabalhos relacionados ao tema da pesquisa.
São considerados os trabalhos relevantes que, de alguma maneira, tratam do assunto de
integração de dados entre bancos de dados relacionais e bancos de dados NOSQL. O capítulo 3 aborda os fundamentos técnicos que são necessários à compreensão do contexto
em que a pesquisa foi realizada. O capítulo 4 apresenta o método proposto a fim suprir as
necessidades identificadas durante a pesquisa, além de apresentar a definição do escopo
do projeto. O capítulo 5 apresenta a estrutura do protótipo que foi desenvolvido a fim demonstrar a viabilidade do método proposto. Além disso, apresenta os resultados obtidos
através da utilização do protótipo. E para finalizar, o capítulo 6 expõe as conclusões que
foram obtidas no desenvolvimento do trabalho e trabalhos futuros.
CAPÍTULO 2
Trabalhos Relacionados
O acesso a dados armazenados em bancos de dados relacionais e NOSQL, por
meio de uma única consulta, é uma necessidade para um crescente número de aplicações.
Os trabalhos discutidos a seguir enfatizam alguns métodos propostos que viabilizam a
integração de dados entre essas duas abordagens de bancos de dados, e a execução de
consultas em bancos de dados NOSQL utilizando a linguagem de consulta SQL, bem
como a forma de acesso aos respectivos bancos de dados.
2.1
Integração de dados entre bancos de dados relacionais e NOSQL
O trabalho de Zhang et al. [45] apresenta um modelo de middleware que controla
a comunicação da consulta SQL de entrada com bancos de dados relacionais e NOSQL.
De acordo com os autores, o middleware é capaz de integrar dados armazenados nos dois
tipos de bancos de dados e, para isso, é necessário configurar os bancos de dados a serem
consultados através de um dicionário de dados, que tem a finalidade de armazenar os
metadados de conexão, como o nome do banco de dados, nome de usuário, senha, porta
de comunicação, além de outros elementos necessários para realizar consultas.
O funcionamento do middleware é ilustrado por meio de uma consulta nos
bancos de dados Oracle e Cassandra, relacional e NOSQL respectivamente. A consulta
fornecida é escrita dentro dos padrões da linguagem SQL. O nome de uma relação é
utilizado para identificar o banco de dados. Assim, para evitar ambiguidades, não é
permitido que bancos de dados do mesmo domínio tenham relações com nomes iguais.
Não é claro, contudo, se o middleware é capaz de executar consultas contendo junções e
outros elementos que não são reconhecidos por bancos de dados da abordagem NOSQL.
A Figura 2.1 apresenta a estrutura do método proposto em [45]. Sua estrutura
foi projetada em três partes. Na camada de aplicação é apresentado o middleware client,
responsável pelo envio de um comando SQL para o middleware server. O middleware
server recebe a consulta SQL e extrai cada elemento que compõe a consulta (relações,
2.1 Integração de dados entre bancos de dados relacionais e NOSQL
8
Figura 2.1: Middleware de integração de dados criado em [45]
atributos e predicados). Em seguida, é realizada uma consulta ao dicionário de dados para
verificar qual banco de dados mantém uma determinada relação informada na consulta.
Em seguida, são construídas novas consultas SQL, sendo uma para cada banco de dados
envolvido na consulta. Em razão de bancos de dados NOSQL não fornecerem padrões de
consultas, o módulo SQL engine realiza a conversão de um comando SQL para o padrão
aceito em bancos de dados NOSQL. O SQL processor é responsável por preparar, analisar
e enviar para os bancos de dados o comando SQL solicitado. O Result Set Handler recebe
os resultados parciais gerados em cada banco de dados e apresenta o resultado de forma
unificada.
Os resultados produzidos neste trabalho tem o objetivo de avaliar o desempenho
de uma aplicação sem a utilização do método proposto e com a utilização do método
proposto, não sendo citados experimentos realizados para avaliar a integração dos dados.
Alguns aspectos do método proposto em [45] diferem do método proposto neste
trabalho: na cláusula select da consulta SQL inicial, os atributos devem ser escritos no
formato relação.atributo. No método proposto neste trabalho, pode-se informar apenas o
atributo. Além disso, o método proposto neste trabalho permite executar consultas envolvendo duas categorias de bancos de dados NOSQL (orientados a colunas e documentos),
além de permitir executar consultas com junções e elementos de agregação em bancos de
dados NOSQL.
O trabalho de Lawrence [17] aborda a integração de dados entre bancos de dados
relacionais e NOSQL. A contribuição do trabalho é propor uma interface de consultas
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
9
SQL que é capaz de traduzir a consulta SQL inicial no padrão da API de cada banco de
dados e executar a consulta. Para uma consulta em banco de dados relacional é aplicado
um módulo que valida os atributos e as relações da consulta. De acordo com o autor,
por não fornecer uma padronização e não armazenar os dados em um esquema definido,
para consultas em banco de dados NOSQL, a validação é realizada durante a execução da
consulta. O autor afirma ser possível realizar consultas com vários operadores, tais como:
join, group by, order by e having.
A partir de uma consulta SQL de entrada contendo relações do banco de dados
MySQL e MongoDB, são criadas novas consultas SQL para cada relação informada na
consulta inicial. Essas consultas são executadas separadamente em cada fonte de dados
com o auxilio da API JDBC. Para processar o resultado final da consulta, se as relações
da consulta de entrada estiverem armazenadas no banco de dados MySQL, a consulta de
entrada é executada neste banco de dados. Se as relações da consulta de entrada estiverem
armazenadas no banco de dados MongoDB, a consulta é executada neste banco de dados
e as junções são executadas em uma camada denominada Virtualization Layer.
O método proposto identifica o banco de dados em que cada relação está
armazenada, colocando como prefixo em cada relação na cláusula from o nome do banco
de dados, por exemplo: select nome from mysql.Cliente. A maneira como é realizada
a conexão com os bancos de dados e possíveis metadados utilizados para executar a
conexão não são explicados pelo autor. Neste aspecto, há uma diferença entre o trabalho
de Lawrence e o método proposto neste trabalho: no método proposto, o banco de dados é
identificado através de um conjunto de metadados de conexão previamente configurados,
não sendo necessário conhecer o banco de dados e sua localidade em que as relações estão
armazenadas.
A avaliação desta proposta foi realizada por meio de operações de consulta nos
bancos de dados já mensionados, sobre os quais foram realizados testes de desempenho.
Os testes realizados indicam que, com a utilização do método proposto, houve um
aumento de menos de 15% no tempo de consulta na maioria das operações realizadas,
em comparação ao tempo de consulta executada diretamente no MongoDB, exceto na
operação de inserção, em que obteve um resultado maior em relação ao tempo de consulta
utilizando o método proposto.
2.2
Integração de dados entre bancos de dados relacionais e outras fontes de dados
Alguns métodos para integração de dados entre diferentes fontes de dados são
propostos por diversos autores, mas não abordam especificamente bancos de dados
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
10
relacionais e NOSQL. Entretanto, é relevante mensionar alguns trabalhos que propõe
integração de dados com outras fontes de dados, a fim de apresentar técnicas que foram
utilizadas para realizar a integração e que foram aplicadas no método proposto neste
trabalho.
O trabalho de Kozlova et al. [16] aborda o processamento integrado de consultas
em bancos de dados relacionais e bancos de dados XML. O método proposto é construído com base em outro trabalho desenvolvido pelos mesmos autores, em que foi implementada uma ferramenta chamada SQXML para validar o método proposto. O problema
aborda um contexto em que uma consulta inicial do usuário, no formato XML ou SQL, é
enviada para bancos de dados relacionais ou XML. Os autores argumentam a importância
de se construir uma visão, com base nos bancos de dados, para cada tipo de informação
gerada no processamento da consulta. O método é capaz de converter um comando SQL
inicial em novas consultas no formato XML ou SQL, que são encaminhadas para cada
banco de dados de dados. Os resultados obtidos em cada banco de dados são tratados pelo
método proposto a fim de apresentar uma única resposta.
O funcionamento do método estabelece a seguinte lógica: a partir da consulta
inicial, um módulo denominado Query Process Component executa os procedimentos
para identificar os atributos e as relações. Em seguida, são construídas novas consultas
SQL, uma para cada banco de dados, para serem utilizadas na construção da visão SQL e
XML. As consultas construídas são convertidas no formato SQL e XQuery e são enviadas
para cada banco de dados. Os resultados obtidos em cada banco de dados são retornados
para o componente Query Process Component. Os resultados obtidos em um banco de
dados XML são enviados para uma relação temporária em banco de dados relacional. No
fim do processo, os dados são apresentados de forma unificada.
Su et al. [38] abordam o problema dos diferentes tipos de dados que são gerados
pelas aplicações e os diferentes tipos de bancos de dados existentes que manipulam os
dados.
Os autores propõem um middleware que é capaz de interagir com vários bancos
de dados e realizar a integração de dados entre bancos de dados relacionais e fontes de
dados XML. No entanto, os autores citam alguns desafios que são encontrados ao tentar
resolver esse problema: as fontes de dados normalmente não são apenas estruturadas;
cada banco de dados usa sua própria maneira de manipular os dados; a integração de
dados requer um modelo de dados em comum para facilitar a manipulação de diferentes
tipos de dados; o ambiente do usuário é dinâmico; várias soluções de integração de dados
necessitam de interação com o usuário.
Para permitir que os bancos de dados sejam acessíveis, o método permite o
registro de metadados de conexão dos bancos de dados (XML ou relacional). Para bancos
de dados relacionais, são aceitos os metadados: tipo (relacional ou XML), nome do
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
11
SGBD, nome do banco de dados, endereço IP, porta de comunicação, usuário e senha do
banco de dados. Para bancos de dados XML, são aceitos os metadados: tipo (relacional
ou XML), nome do documento XML que representa o banco de dados, endereço IP do
servidor.
Para realizar uma consulta, a aplicação realiza os seguintes procedimentos: é
feita a análise da consulta inicial para identificar palavras-chaves, nomes de relações, atributos e predicados. Em seguida, são agrupados os atributos e predicados de cada relação,
criando novas consultas SQL. Após esse procedimento, as consultas são transformadas
no padrão desejado, por exemplo: se a consulta for para um banco de dados relacional,
a consulta é executada diretamente no banco de dados; se a consulta for executada em
fontes XML, é feita a transformação da consulta no padrão da linguagem XQuery. Após
esses procedimentos, os resultados obtidos em cada consulta são integrados em um único
resultado final através de um documento XML.
O trabalho de Calil e Dos Santos [4] aborda a execução de comandos DML (inserir, alterar, excluir e consultar) em um banco de dados NOSQL orientado a documentos,
chamado SimpleDB, utilizando a linguagem de consulta SQL.
Para criar uma interface relacional para o banco de dados SimpleDB, é feito um
mapeamento dos elementos que compõe a estrutura de um banco de dados relacional para
a estrutura do banco de dados SimpleDB. Esse mapeamento é utilizado em vários processos para converter um elemento SQL em um elemento do banco de dados SimpleDB.
Estrutura relacional e SimpleDB
Relacional
SimpleDB
Esquema
Domínio
Relação
-
Tupla/Linha
Item
Atributo
Atributo chave
Valor
Valor do atributo
Chave primária
Nome do item
Tabela 2.1: Mapeamento da estrutura de um banco de dados relacional para o banco de dados SimpleDB [4].
A Tabela 2.1 apresenta o mapeamento desenvolvido pelos autores para relacionar
os elementos contidos em um banco de dados relacional com o banco de dados SimpleDB.
A estrutura do método proposto é apresentado na Figura 2.2. Os módulos que
compõe a estrutura do método proposto são: Access Interface, Command Decomposition
e Processing and Return.
• Access Interface: este processo é composto por dois métodos: ExecuteQuery, que
retorna um resultado em formato de tabela, e ExecuteNonQuery, que retorna um
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
12
Figura 2.2: Estrutura do método criado em [4].
texto (string) como resultado. Em operações de inserção, alteração e exclusão,
é utilizado o segundo método; para operação de consulta, é utilizado o primeiro
método. A operação de consulta permite a utilização de junção, mas não permite
agrupamento e subconsultas. Se a consulta é composta por junção, os atributos
devem ser precedidos pelo nome da relação (ex.: relação.atributo).
• Command Decomposition: este processo é responsável por segmentar o comando
SQL e converter os elementos SQL para o formato do SimpleDB. Para uma operação de consulta, são extraídos os elementos: atributos, relações, junções e predicados, porém, os autores não comentam onde são armazenados esses elementos
temporariamente.
• Processing and Return: este processo é responsável por executar o comando SQL
no SimpleDB. Em operações de consulta, se houver mais de uma relação referenciada através de junção, são criadas novas consultas, uma para cada relação da consulta inicial, composta pelos atributos e condições específicas de cada relação. Os
resultados processados em cada relação são mesclados usando as chaves estrangeiras do modelo relacional e o resultado final é fornecido no formato de tabela.
Os resultados obtidos através de experimentos avaliam o desempenho das operações de inserção e consulta. Na inserção, é avaliado o tempo gasto para inserir um grande
volume de dados. Na consulta, é avaliado o tempo gasto para executar diferentes consultas
em termos de complexidade.
• Nas operações de consulta, houve um aumento de aproximadamente 40% no tempo
de processamento, em comparação ao tempo gasto em executar diretamente no
SimpleDB. De acordo com os autores, era esperada essa diferença no tempo, pois
o método proposto processa dados consultados em bancos de dados nas nuvens e
converte para o esquema relacional.
• Nas operações de inserção, houve um aumento de aproximadamente 5% no tempo
de processamento, em comparação ao tempo gasto em executar diretamente no
SimpleDB. De acordo com os autores, esse aumento no tempo não é um obstáculo
para adotar o método proposto.
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
13
O trabalho de Dos Santos et al. [10] aborda a execução de comandos DDL (criar,
alterar e excluir relações) em um banco de dados NOSQL orientado a documentos chamado SimpleDB, utilizando a linguagem de consulta SQL. Os autores citam a necessidade
de se utilizar os recursos oferecidos pela linguagem de consulta SQL em conjunto aos recursos oferecidos pelos bancos de dados NOSQL, sem afetar o desempenho da aplicação.
O método proposto é uma evolução daquele discutido em [4], que agora permite executar
os dois tipos de comandos SQL, tanto DML quanto DDL.
O método desenvolvido em [10] é chamado de SimpleSQL e pode receber um
comando DDL, converter para a estrutura do banco de dados SimpleDB e executar o
comando. Para isso, a estrutura de um banco de dados relacional é mapeada para a
estrutura do banco de dados SimpleDB, conforme a Tabela 2.1.
Para iniciar a execução do método, o comando DDL é recebido pelo módulo
Access Inteface, que é responsável por identificar o comando SQL. Após esse procedimento, o módulo Command Translation identifica o banco de dados, relações, colunas e
restrições do comando inicial a fim de mapear os elementos SQL para o SimpleDB. De
acordo com os autores, esse mapeamento é realizado com base em expressões regulares,
que tem o objetivo de validar a sintaxe do comando a ser processado e extrair os elementos correspondentes para o SimpleDB. Por fim, o módulo Processing and Return recebe
os dados e o comando a ser processado e os envia ao SimpleDB. O resultado da operação
executada é encaminhada para o módulo Access Interface e posteriormente enviada para
a aplicação. A estrutura do método é apresentada na figura 2.3.
Figura 2.3: Estrutura do método desenvolvido em [10].
Os experimentos realizados pelos autores avaliaram o tempo de processamento
da execução de comandos DDL com a utilização do método proposto. Os resultados
apontam que, com a utilização do SimpleSQL, o tempo de execução de comandos DDL
é satisfatório, em comparação com a execução de comandos através do SimpleDB. Em
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
14
operações de criação de relações, por exemplo, houve um aumento no tempo de execução
do comando, porém, inferior a 34%, em comparação ao tempo de execução do comando
no SimpleDB. Em operações de atualização e exclusão de relações, o tempo de execução
dos comandos foi inferior a 15%.
Chung et al. [9] abordam as mudanças ocorridas nos meios de armazenamento,
em que os bancos de dados relacionais são utilizados em grande parte das situações pra
manipular dados.
É proposto um mecanismo em que é submetida uma consulta SQL para ser
executada por bancos de dados NOSQL. O método proposto permite a execução apenas
de consultas e em apenas um banco de dados NOSQL, no caso, HBase. Para controlar
o acesso ao banco de dados HBase, é utilizada a API JDBC. Para processar os dados, é
utilizada a técnica MapReduce, que tem a função de processar dados não estruturados no
banco de dados NOSQL.
Para criar um modelo semelhante às duas abordagens (estruturada e NOSQL),
é feito um mapeamento da estrutura do relacional para a estrutura do HBase. Para isso,
são configurados os metadados de armazenamento no banco de dados relacional Derby.
Os metadados configurados são: o nome da tabela, o nome da família de colunas e das
colunas do HBase.
Os passos executados para submeter uma consulta e receber o resultado são:
1. Submeter a consulta no padrão ANSI-SQL através de uma aplicação cliente que
ofereça a utilização da linguagem SQL (neste trabalho foi utilizado o SQuirreL).
2. Analisar e mapear a consulta.
3. Encontrar o nome da tabela, família de colunas e colunas do HBase.
4. Gerar o MapReduce de acordo com a consulta e os metadados.
5. Acessar o HBase e executar o MapReduce.
6. Apresentar os resultados.
O método proposto foi avaliado através da execução de várias consultas SQL
contendo vários elementos não executados de forma nativa pelos bancos NOSQL (sum,
group by e outros). Os experimentos consideram o tempo de execução de consultas
utilizando o método proposto, Hive e MySQL. Os experimentos foram executados em um
ambiente contendo dados entre 100GB e 700GB de tamanho, utilizando consultas com
select, between, like, group by, group by, order by e join. De acordo com os resultados
obtidos, o método proposto supera, em tempo de execução das consultas, o Hive e
MySQL, em todas as consultas, exceto as consultas envolvendo join, sendo inferior apenas
ao MySQL.
O trabalho de Duggan et al. [11] aborda uma nova visão de bancos de dados
federados com a crescente necessidade de gerenciamento de informações que abrange
vários modelos de dados.
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
15
A partir dos trabalhos relacionados com a proposta deste trabalho, foi criada uma
tabela que apresenta algumas caracteristicas que diferenciam os trabalhos apresentados
nesta seção e o método proposto neste trabalho.
Zhang et al.
[45]
Lawrence
[17]
Kozlova et
al. [16]
Su et al. [38]
Calil e Dos
Santos [4]
Dos Santos
et al. [10]
Chung et al.
[9]
Método proposto 2015
Sim
Sim
Não
Não
Não
Não
Sim
Sim
Sim
Sim
Sim
Não
Não
Não
Sim
Utiliza
JDBC
Acessa
vários
bancos
Sim
metada-
Sim
Sim
Não
Não
Não definido
Não definido
Não definido
Não definido
Sim
Não
Não
Sim
Não definido
Sim
Não definido
Não
Sim
Não
Não
Não
Não
Não definido
Não
Conhecimento Conhecimento Várias
prévio BD
prévio rela- categorias
ção
NOSQL
Não
Sim
Não
Tabela 2.2: Características dos trabalhos relacionados
Não definido
Sim
Não definido
Não
Sim
Sim
Usa
dos
Não
Não
Não
Sim
Não
Não
Não
Consulta
préprocessada
Não
Sim
Sim
Sim
Não definido
Sim
Não definido
Sim
Não
Permite Join
Sim
Sim
Não
Não definido
Não
Não definido
Sim
Elementos
de
agregação (sum,
count...)
Não
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
16
2.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados
17
A Tabela 2.2 apresenta os elementos que foram utilizados para comparar os
trabalhos apresentados nesta seção com o método proposto neste trabalho.
• Acessa vários bancos: o método proposto permite acessar vários bancos de dados
a partir da consulta de entrada.
• Utiliza JDBC: o método proposto utiliza driver JDBC específico de cada banco de
dados envolvido na consulta de entrada.
• Usa metadados: o método proposto utiliza o mecanismo de configuração prévia de
metadados de conexão.
• Conhecimento prévio BD: o método proposto identifica o banco de dados que
mantém uma relação a partir de um indicativo do banco de dados (nome do banco
ou algo que o identifica), precedendo-o em uma relação na consulta de entrada.
• Conhecimento prévio relação: o método proposto exige preceder o nome do
atributo com o nome da relação a qual pertece.
• Várias categorias NOSQL: o método proposto permite acessar várias categorias
de bancos de dados NOSQL a partir de uma única consulta SQL de entrada.
• Consulta pré-processada: a consulta de entrada não é informada no padrão SQL.
• Permite Join: o método proposto permite utilizar, na consulta SQL de entrada,
operação de junção.
• Elementos de agregação (sum, count...): o método proposto permite utilizar, na
consulta SQL de entrada, elementos de agregação.
CAPÍTULO 3
Fundamentação teórica
Este capítulo apresenta os conceitos, estruturas e modelos de bancos de dados
relacionais, bancos de dados NOSQL e outros assuntos necessários ao entendimento deste
trabalho.
3.1
Modelo relacional
Por se tratar de um modelo de dados bastante testado, documentado e fundamentado, não será feita uma abordagem profunda nas teorias do modelo relacional.
O modelo relacional é caracterizado por descrever os dados em uma estrutura
chamada esquema. No modelo relacional, o esquema especifica as relações, os atributo e
o tipo de dado ou domínio de cada atributo [31]. Os dados são armazenados em relações,
as quais são compostas por um conjunto de tuplas. Os dados podem ser armazenados em
múltiplas relações, permitindo executar consultas relacionando várias relações através de
junções [28], [15]. Os bancos de dados que são originados desse modelo são conhecidos
como bancos de dados relacionais.
Os bancos de dados relacionais utilizam a linguagem de consulta SQL, que
permite o acesso e a manipulação de dados. A linguagem de consulta SQL contém
elementos que permitem a criação, alteração, exclusão e consulta de dados nos bancos
de dados. Além disso, fornece uma sintaxe padrão que auxilia o acesso e manipulação
dos dados [31], [15].
Um dos recursos importantes do modelo relacional, e que o difere de outros
modelos, são as propriedades ACID [31], que é o acrônimo de atomicidade, consistência,
isolamento e durabilidade. Essas propriedades asseguram a consistência e a integridade
dos dados, além de oferecer recursos de transação entre a aplicação e o banco de dados
[24], [15], [21]. Em casos específicos, o controle de transação é importante, como em
sistemas bancários, em que se deve garantir a integridade dos valores gerados por uma
transação [29].
Os bancos de dados relacionais são utilizados em grande parte das aplicações,
por se tratar de um modelo bastante estudado, matematicamente fundamentado e utilizado
3.1 Modelo relacional
19
amplamente para o armazenamento de dados. Aplicações que priorizam a consistência dos
dados, controle de transações, consultas que envolvam operadores de agregação, soma,
contagem, junções e outras características, utilizam os bancos de dados relacionais como
fonte de armazenamento. De acordo com Leavitt [18] e Mohamed et al. [21], a abordagem
relacional é utilizada em aplicações de negócios, tais como: bancos, indústrias, empresas
comerciais, em que é necessário obter informações com garantia da consistência dos
dados e consultas com as características citadas.
Existem, entretanto, algumas limitações na utilização de bancos de relacionais
no armazenamento de dados. Os bancos de dados relacionais não são adequados para
lidar com a grande massa de dados gerados na Web, com milhões de acessos simultaneos
[21], [25]. De acordo com Leavitt [18], os dados produzidos por usuários, para serem
armazenados no banco de dados, devem ser convertidos para estrutura de relações. Essa
tarefa se torna difícil e lenta em bancos de dados relacionais, por se tratar de uma estrutura
com um esquema defido. A escalabilidade da aplicação se torna inviável, por distribuir os
dados em servidores com maior poder de processamento e mais caros [25].
Tauro et al. [39] abordam três aspectos principais que resultam à não utilização
de bancos de dados relacionais em alguns tipos de aplicações: (1) o conjunto de dados
disponíveis para ser acessado é cada vez maior; (2) a disponibilidade da aplicação; (3) os
tipos de dados disponíveis, em grande parte, são não estruturados.
Figura 3.1: Tipos de dados gerados nos últimos anos [39].
De acordo com os autores, a quantidade de dados gerados na Web entre os anos
de 2007 e 2010 aumentou em vinte e cinco vezes. A Figura 3.1 apresenta os tipos de
dados gerados nos últimos anos segundo as pesquisas. Na década de 90 eram produzidos
3.2 Abordagem NOSQL
20
na Web apenas documentos de texto e hipertextos. Entre os anos de 2000 a 2010, com
o surgimento da Web 2.0, foram produzidos outros tipos de dados, tais como blogs,
conteúdos de usuários e outros. Atualmente e nos próximos anos, são e serão gerados
dados como ontologias, RDF e outros.
Tauro et al. [39] ainda abordam o problema em utilizar bancos de dados relacionais na manipulação de dados semi-estruturados. Os bancos de dados relacionais possuem
uma estrutura definida, na qual exigem a prévia definição da estrutura de armazenamento,
informando o nome e o tipo do atributo, bem como a quantidade de atributos [18]. Dados
semi-estruturados são dados que possuem atributos não definidos e opcionais. À medida
que as informações aumentam, é necessário aumentar, por exemplo, o número de colunas
de uma relação.
3.2
Abordagem NOSQL
A abordagem NOSQL foi proposta com o objetivo de oferecer novas maneiras
no armazenamento de dados com ênfase no armazenamento de grandes massas de
dados, disponibilidade e escalabilidade da aplicação [25]. Essa abordagem foi proposta
inicialmente em 1999 por Carlos Strozzi, no entanto, passou a se tornar mais conhecida
a partir de 2009, através de Johan Oskarsson, em um evento que discutia bancos de
dados distribuídos e open-source [45]. Desde então, empresas como Google, Facebook
e Amazon passaram a desenvolver suas próprias soluções NOSQL.
Os bancos de dados NOSQL são representados em uma estrutura denominada
esquema, porém, não é necessário sua definição prévia [40]. Nessa abordagem, os dados
são armazenados como um par chave-valor, em que a chave é única e identifica o registro
e o valor representa a informação de uma determinada chave.
Os bancos de dados NOSQL foram projetados para oferecer, prioritariamente,
alta disponibilidade, diferente da abordagem relacional, que prioriza a consistência dos
dados. Alguns bancos de dados NOSQL oferecem a escalabilidade horizontal, em que os
dados são distribuídos em computadores com menor poder de processamento, em vez de
serem distribuídos em um único servidor com maior poder de processamento. Em alguns
casos, bancos de dados NOSQL permitem melhor desempenho de processamento de
operações SQL em comparação com bancos de dados relacionais e se tornam adequados
em aplicações que manipulam grandes volumes de dados, na ordem de zetabytes ou
petabytes [18] [33], [8], [25].
Tudorica e Bucur [40] abordam as principais características e categorias dos
bancos de dados NOSQL. Estes bancos de dados não oferecem relacionamentos entre
os dados, não utilizam a linguagem de consulta SQL para operações com banco de dados,
sendo necessário uma API de comunicação com banco de dados para realizar operação
3.2 Abordagem NOSQL
21
de inserção, alteração, exclusão e consulta de dados. De acordo com as pesquisas, foi
constatado que grande parte dos bancos de dados NOSQL são open-source. Segundo
Lawrence [17], bancos de dados NOSQL foram desenvolvidos para suprir os recursos que
o modelo relacional não oferece, frequentemente envolvendo recursos de processamento
de Big Data.
3.2.1
Modelo de dados
A principal característica que difere o modelo relacional da abordagem NOSQL
é o modelo de dados [14]. A abordagem NOSQL busca oferecer maneiras diferentes para
armazenar os diversos tipos de dados que são gerados ou consumidos pelas aplicações.
Basicamente, todos os bancos de dados NOSQL armazenam os dados em um par chavevalor, porém, disponibilizam estruturas diferentes no armazenamento [14].
3.2.2
Categorias de bancos de dados NOSQL
Os bancos de dados NOSQL são divididos em quatro principais categorias:
chave-valor, orientado a colunas, orientado a documentos e orientado a grafos. Tudorica e
Bucur [40], Cattell [8], Hecht e Jablonski [14], Han et al. [13] são alguns dos autores que
abordam as categorias NOSQL e comentam sobre os bancos de dados de cada categoria.
1. Chave-Valor
É o modelo de dados mais simples, em que cada valor corresponde a uma chave.
Permite armazenamento de grande massa de dados e as modificações nos valores
ocorrem através das chaves [13]. Uma determinada pesquisa pode ser feita apenas
pela chave, pois não é possível agrupar várias chaves em algum tipo de estrutura,
como ocorre em outras categorias NOSQL. Esta categoria permite, além de um
mecanismo de armazenamento: replicação, versionamento, transações, ordenação e
outros recursos [8], [14].
De acordo com [14], por se tratar de um modelo de dados simples, as APIs de
consulta disponíveis para esta categoria não fornecem tantos recursos quanto as
de outras categorias NOSQL, fornecendo apenas os métodos: put, get e delete.
Se é necessário realizar algum tipo de consulta mais complexa, esta deve ser
implementada na aplicação. Portanto, a categoria chave-valor não deve ser utilizada
em casos que envolva consultas complexas. A Figura 3.2 exemplifica a estrutura da
categoria NOSQL chave-valor. Cada linha corresponde a um par <chave,valor>.
Riak, Redis, Scalaris, MemcacheDB são exemplos de bancos de dados chave-valor
[40].
2. Documentos
3.2 Abordagem NOSQL
22
Figura 3.2: Estrutura do banco de dados chave-valor
Este modelo armazena um par chave-documento em um documento JSON ou
XML. Em cada documento, a chave que identifica um valor deve ser única e
contém uma chave especial chamada ID, que também é única, que identifica
o documento explicitamente dentro de uma coleção de documentos [14]. Uma
coleção de documentos compõe um banco de dados. Em cada banco de dados, podese ter tipos diferentes de documentos, documentos aninhados e permite a criação de
índices secundários [8]. CouchDB, MongoDB, OrientDB, RavenDB são exemplos
de bancos de dados NOSQL orientados a documentos [40], [8]. Para exemplificar a
estrutura dos bancos de dados orientados a documentos, será utilizado o banco de
dados MongoDB.
Figura 3.3: Estrutura do banco de dados MongoDB [43]
A Figura 3.4 apresenta a estrutura de armazenamento do MongoDB. Os documentos são compostos por vários atributos, porém, cada atributo é composto apenas
pelo seu valor.
MongoDB é um banco de dados escrito na linguagem C++ e possui algumas
características: a chave que identifica um documento normalmente é a combinação
do ID e um valor timestamp; implementa uma linguagem própria de consulta;
3.2 Abordagem NOSQL
23
oferece técnicas de distribuição de documentos em vários servidores através da
replicação de dados, permitindo master-slave, que é mais utilizado em caso de
falha de leitura ou escrita, e sharding, utilizado para a escalabilidade horizontal,
o que garante a durabilidade dos dados [8], [1]. A Figura 3.3 apresenta a estrutura
básica do banco de dados MongoDB.
Figura 3.4: Exemplo da estrutura de armazenamento do MongoDB
Na abordagem relacional, alguns termos são utilizados para identificar os elementos
que compõe a estrutura dos bancos de dados relacionais. É possível fazer uma
analogia com o MongoDB e mostrar a terminologia empregada nos elementos que
compõe a estrutura do banco de dados.
Termos SQL
Banco de dados
Tabela
Linha
Coluna
Index
Primary Key
Termos MongoDB
Banco de dados
Coleção
Documento ou JSON
Campo
Index
Primary key
Tabela 3.1: Comparação dos termos utilizados em bancos de dados relacionais e MongoDB [22]
A Tabela 3.1 apresenta os termos que são empregados em elementos dos bancos
de dados relacionais e seus correspondentes no banco de dados MongoDB. Alguns
termos, tais como index, primary key e banco de dados tem o mesmo significado em
ambos, enquanto as informações dos registros armazenados (tabela, coluna e linha)
são diferentes.
O banco de dados MongoDB utiliza mecanismos diferentes de manipulação de
dados em comparação aos bancos de dados relacionais. É possível realizar uma
comparação sintática de como é feita a criação de uma relação, inserção e consulta
dos dados em um banco de dados relacional e no banco de dados MongoDB.
3.2 Abordagem NOSQL
24
A Figura 3.5 apresenta uma comparação sintática para criação de uma relação em
um banco de dados relacional e a criação de uma coleção de documentos no banco
de dados MongoDB. Ao criar uma relação chamada users em um banco de dados
relacional, é necessário definir o tipo de dado e outros atributos. No banco de dados
MongoDB, entretanto, não é necessário definir os atributos de cada documento.
Opcionamente, não é necessário criar explicitamente uma coleção de documentos;
ao executar o comando para inserir um documento, a coleção de documentos é
criada automaticamente.
Figura 3.5: Comparação da sintaxe de criação de uma relação em
banco de dados relacional e MongoDB [22]
A Figura 3.6 apresenta a sintaxe utilizada para inserir dados em uma relação do
banco de dados relacional e em um documento no banco de dados MongoDB. Para
inserir dados em um banco de dados relacional, é possível utilizar uma relação
que foi criada, mas não utilizada no momento da criação. No banco de dados
MongoDB, pode-se utilizar uma coleção de documentos já criada ou informar o
nome da coleção de documentos no momento da inserção dos dados.
Figura 3.6: Comparação da sintaxe de inserção de dados em
banco de dados relacional e MongoDB [22]
A Figura 3.7 apresenta a sintaxe para consultar dados em um banco de dados
relacional e em um documento no banco de dados MongoDB. É possível verificar
que o banco de dados MongoDB não utiliza a linguagem SQL para consulta de
dados, mas sim, uma API que realiza as operações com o banco de dados. Assim
como a linguagem SQL oferece a operação select, o banco de dados MongoDB
oferece o método find(), que tem a tarefa de pesquisar os dados dentro de uma
coleção de documentos.
3.2 Abordagem NOSQL
25
Figura 3.7: Comparação da sintaxe de consulta em banco de dados relacional e MongoDB [22]
3. Grafos
Bancos de dados orientados a grafos são especializados em gerenciar dados fortemente ligados. Para aplicações baseadas em dados com relacionamentos, tais como
mapas, serviços de localização, é recomendada a utilização desta categoria de banco
de dados NOSQL [14].
Nesta categoria, os nós e arestas consistem de objetos com atributos chave-valor
embutidos. A quantidade de pares <chave, valor> é definida pelo esquema do banco
de dados, em que uma expressão que envolva restrições de maior complexidade
pode ser descrita facilmente [14].
Em contraste com outras categorias NOSQL, a categoria NOSQL orientado a grafos
oferece algumas linguagens de consulta, tais como SPARQL e Gremlin. Entretanto,
exemplos de bancos de dados que apoiam essas linguagens de consulta são Neo4J
e GraphDB, diferente do FlockDB, que não apoia a utilização destas linguagens de
consulta [14].
Um caso de utilização da categoria NOSQL orientado a grafos é o Twitter. A rede
social armazena vários relacionamentos entre os usuários a fim de fornecer o serviço
de pesquisa de tweets. É utilizado o banco de dados FlockDB para armazenar os
relacionamentos, e, de acordo com [14], é um banco de dados mais simples em
comparação a outros da categoria NOSQL.
Neo4J, InfoGrid, HyperGraphDB, VertexDB são exemplos de orientado a grafos
[40].
4. Colunas
3.2 Abordagem NOSQL
26
A categoria banco de dados orientado a colunas é o modelo que mais se assemelha
com bancos de dados relacionais, que armazena as informações em relações, mas
não permite relacionamentos entre elas. Os dados são armazenados separadamente
em colunas e cada coluna de dados é um índice do banco de dados. As colunas
podem ser agrupadas em famílias de colunas, que permitem sua distribuição em
vários nós, o que torna importante para a organização e particionamento dos dados
[13], [8], [14], [1]. Cassandra, Hypertable, Hbase, Amazon SimpleDB são exemplos
de bancos de dados orientados a colunas [40]. Para exemplificar a estrutura dos
bancos de dados orientados a colunas, será utilizado o banco de dados Cassandra.
Cassandra é um banco de dados escrito em Java, desenvolvido pelo Facebook e
possui algumas características: permite armazenar dados estruturados, semi estruturados e não estruturados; projetado para armazenar grande quantidade de dados.
Quando, em algum cluster, algum nó é adicionado ou removido, os dados são distribuídos automaticamente em todos os nós do cluster [1].
Figura 3.8: Estrutura de armazenamento do banco de dados Cassandra
A Figura 3.8 exemplifica a estrutura de armazenamento do banco de dados Cassandra. É possível identificar que o keypace é responsável por armazenar toda a
estrutura de armazenamento. Uma família de colunas é composta por linhas e cada
linha é formada por colunas e um atributo chave. Em analogia a bancos de dados
relacionais, o keyspace é equivalente ao banco de dados, uma família de colunas
equivale a uma relação e uma coluna é comparada a um atributo [1].
O Cassandra oferece uma linguagem de consulta própria chamada CQL (Cassandra
Query Language), que se assemelha à linguagem SQL, que utiliza o mesmo conceito de estruturação das relações em linhas e colunas [7]. A linguagem CQL não
3.2 Abordagem NOSQL
27
oferece algumas operações com banco de dados, tais como: junções, subconsultas,
agrupamentos e outras operações [7].
Comandos CQL
SELECT * FROM users WHERE firstname = "jane"and lastname="smith";
SELECT * FROM emp WHERE empID IN (130,104) ORDER
BY deptID DESC;
SELECT * FROM emp where empID IN (130,104) ORDER BY
deptID ASC;
SELECT artist, venue FROM playlists WHERE venue CONTAINS "The Fillmore";
Tabela 3.2: Exemplos de consultas utilizando o CQL [7]
A Tabela 3.2 apresenta exemplos de consultas utilizando a linguagem CQL. A
cláusula select permite operações com nomes de atributos, count(*), distinct e
utilização de alias com a expressão as. Na cláusula where, é permitida a utilização
dos elementos: and, in, contains, =, <, >, <=, >=. Na cláusula order by, é permitido
ordenação pelo nome dos atributos especificados na cláusula select e não pelo alias,
contendo as expressões asc e desc. Mais informações sobre a linguagem CQL estão
disponíveis em [6].
Figura 3.9: Exemplo da sintaxe de criação de relações CQL [7]
A Figura 3.9 apresenta a sintaxe de criação de relações no banco de dados Cassandra utilizando a linguagem CQL. A estrutura é semelhante à linguagem SQL,
podendo conter atributos com os seguintes tipos: ascii, bigint, blob, boolean, counter, decimal, double, float, int, text, timestamp, uuid, varchar, varint [6].
A linguagem de consulta CQL é, ainda, bastante estudada e modificada. O site da
API, disponível em [6], contém o histórico das últimas versões da linguagem CQL,
em que é possível identificar que muitos recursos foram afetados na evolução das
versões, não sendo possível afirmar se um determinado recurso estará presente ou
conterá o mesmo nome ou funcionamento da versão anterior.
3.2 Abordagem NOSQL
3.2.3
28
Outras características da abordagem NOSQL
Tudorica e Bucur [40] comentam que algumas categorias de bancos de dados
possuem características da abordagem NOSQL, porém, oferecem alguns recursos de
bancos de dados relacionais, como a utilização das propriedades ACID. Por esse motivo,
de acordo com os autores, tais categorias são ignoradas por vários autores quando
abordam o assunto NOSQL. Essas outras categorias são: bancos de dados orientado a
objetos, bancos de dados em nuvem, bancos de dados XML, bancos de dados multivalor.
Han et al. [13] analisam as classificações da abordagem NOSQL e a origem
da fundamentação da abordagem. Nesse estudo, foi discutido que a abordagem NOSQL
é baseada nas propriedades CAP, que é o acrônimo de consistência, disponibilidade e
tolerância a partição. Essas propriedades foram fundamentadas em 2000, pelo professor
Eric Brewer, com a construção do teorema CAP. De acordo com ele, em ambientes
distribuídos, é possível oferecer apenas duas das três propriedades simultaneamente.
Figura 3.10: Teorema CAP [42]
A Figura 3.10 apresenta o teorema CAP através da união do conjunto DT, CT
e DC. O centro da figura é apresentado sem nenhum indicativo, demonstrando que não
existe a relação das três propriedades. Alguns autores, tais como Wang e Tang [42], Cattell
[8], Abramova e Bernardino [1], Pokorny [29] também abordam em seus trabalhos, entre
vários temas, a fundamentação da abordagem NOSQL por parte do teorema CAP, fazendo
analogias com as propriedades ACID da abordagem relacional.
De acordo com Tauro et al. [39], a principal vantagem da abordagem NOSQL em
relação à abordagem relacional é a facilidade em manipular dados não estruturados, como
documentos, emails, dados multimídia, dados gerados em redes sociais. Os principais recursos oferecidos pelos bancos de dados NOSQL são: alta escalabilidade, disponibilidade,
modelo de dados sem esquema definido.
Li e Manoharan [19] afirmam que, com o aumento de acesso à Internet, aumentou também a quantidade de dados gerados pelas aplicações, e esses dados podem ser do
3.2 Abordagem NOSQL
29
tipo estruturado, semi-estruturado ou não estruturado. Processar esses dados requer alta
velocidade, esquema de dados flexível e bancos de dados distribuídos. De acordo com os
recursos oferecidos, a abordagem NOSQL é a mais indicada para esses cenários.
Leavitt [18] aborda em seu trabalho o tema: organizações que trabalham com
grande quantidade de dados não estruturados estão, cada vez mais, migrando para bancos
de dados NOSQL. É feito um estudo apontando as principais limitações da abordagem
relacional e os motivos pelas quais várias empresas passaram a utilizar bancos de dados
NOSQL no armazenamento de dados. Entre os principais motivos, estão: rápido acesso
aos dados, modelo de dados simples, escalabilidade horizontal, bancos de dados opensource. O autor comenta que os bancos de dados NOSQL não vão substituir os bancos de
dados relacionais, mas sim, oferecer recursos diferentes para serem implementados em
outros tipos de aplicações.
Alguns autores, tais como Li e Manoharan [19], Parker et al. [28], Wei-ping et al.
[43] e Nyati [27] propõem comparações entre os bancos de dados relacionais e NOSQL
em relação ao tempo e velocidade de execução de operações com o banco de dados.
Bancos de dados
MongoDB
RavenDB
CouchDB
Cassandra
Hypertable
Couchbase
MS SQL Express
No de operações
10 50
100 1000
61 75
84
387
570 898 1213 6939
90 374 616 6211
117 160 212 1200
55 90
184 1035
60 76
63
142
30 94
129 1790
10000
2693
71343
67216
9801
10938
936
15588
100000
23354
740450
932038
88197
114872
8492
216479
Tabela 3.3: Comparação do tempo de inserção entre bancos de
dados NOSQL e relacional [19]
A Tabela 3.3 apresenta as análises feitas em [19], com base no tempo de inserção,
em milissegundos, e a quantidade de operações executadas. Foram feitos testes com 6
bancos de dados NOSQL e 1 banco de dados relacional.
Com 10 operações, o banco de dados MSSQL Express se mostrou mais rápido
que todos os outros bancos de dados. Porém, com 100.000 operações, o banco de dados
Couchbase obteve um resultado de tempo de escrita melhor, seguido pelo MongoDB e
Cassandra. De acordo com os autores, nos testes de leitura e escrita, foram constatados
que alguns bancos de dados NOSQL se mostraram mais lentos que o MSSQL Express,
especialmente os bancos de dados RavenDB e CouchDB. Informações como: utilização
de índices, dados em memória e o volume de dados não foram informados pelos autores.
Parker et al. [28] apresenta o resultado das análises feitas com relação ao tempo
de consulta entre SQL e MongoDB através de um campo indexado. Foram executadas
3.3 Dados estruturados e não estruturados
30
operações SQL nos bancos de dados SQL Server e MongoDB e extraído o tempo, em
milissegundos, de execução das operações. O resultado aponta que o tempo de consulta
no banco de dados SQL é maior que no MongoDB. De acordo com os autores, isso se deve
ao fato do MongoDB utilizar campos indexados, no caso ID, e também por processar as
consultas em memória.
Wei-ping et al. [43] apresentam o resultado das análises realizadas nos bancos
de dados MongoDB e MySQL ao executar operações SQL. O resultado foi obtido através
de duas operações, sendo uma operação de inserção e outra de consulta. Na inserção, o
banco de dados MongoDB apresentou um tempo mais satisfatório que no MySQL. Na
consulta, os dois bancos de dados obtiveram um tempo menor que na inserção, porém, o
MongoDB também alcançou um tempo menor que o MySQL.
Os resultados apresentados acima indicam que as operações realizadas em bancos de dados NOSQL são mais rápidas do que em bancos de dados relacionais. No entanto, não se pode afirmar que os bancos de dados que obtiveram resultados mais satisfatórios no tempo de inserção e consulta de dados são melhores do que os menos satisfatórios.
O que deve ser considerado é o ambiente no qual será utilizado o banco de dados, a quantidade de dados envolvidos no processo, o tipo dos dados gerados pela aplicação, o tipo
da aplicação, as operações que os usuários necessitam e quais os recursos que o banco de
dados pode oferecer. Por exemplo: alguns desses testes podem ter sido gerados em uma
aplicação que realmente faz uso de bancos relacionais, e, de fato, obteve um resultado
menos satisfatório do que os bancos NOSQL. Entretanto, para os usuários e os resultados
esperados pela aplicação, o tempo de resposta da operação pode ser irrelevante, visto que
podem ter outros recursos que são oferecidos pelos bancos de dados relacionais e consumidos pelos usuários, e, por esses motivos, os usuários já sabem que a operação retornará
o resultado em maior tempo.
3.3
Dados estruturados e não estruturados
Os tipos de dados manipulados por aplicações na Web se tornaram cada vez
mais diversificados nos últimos anos, devido ao fácil acesso à Web e a disponibilidade
de armazenar dados com baixo custo [19]. No entanto, existem situações nas quais
são disponibilizados formulários de cadastros para interação com o usuário ou são
armazenados os metadados de dados manipulados pelos usuários [3]. Em geral, os dados
podem residir em registros com estrutura definida, que são classificados como dados
estruturados, ou em arquivos contendo texto, música, gráficos, que são classificados como
dados não estruturados [12].
A Tabela 3.4 apresenta a forma como é representado um dado estruturado. O
exemplo mostra um formulário de contato que possui a mesma estrutura semântica,
3.3 Dados estruturados e não estruturados
31
Formulário de Contato
Atributo
Tipo
Valor
Nome
Texto
José Pereira
Endereco
Texto Rua das flores, no 5
Cidade
Texto
São Paulo
Bairro
Texto
Jardim das Flores
Idade Numero
35
Tabela 3.4: Exemplo de dados estruturados
mesmas características, tipos de dados definidos e mesma quantidade de atributos, em
comparação, por exemplo, a dados encontrados em documentos de texto. Independente da
pessoa que se deseja cadastrar, sempre deverá seguir a estrutura especificada. Além disso,
as informações apresentadas nos contatos são organizadas em linhas e colunas, o que torna
adequado armazenar esses dados em bancos de dados relacionais [28]. Dados estruturados
são dados armazenados em uma estrutura predefinida e que podem ser organizadas em
relações, tags ou objetos [12].
Figura 3.11: Exemplo de dados não estruturados
A Figura 3.11 exemplifica como são encontrados dados não estruturados em um
documento de texto. Neste exemplo é utilizada a localização da palavra "consulta", em
que é possível verificar que todas as palavras e expressões não possuem uma estrutura
definida, sendo distribuídas livremente no texto.
O conceito de dados não estruturados pode ter vários significados dependendo
do contexto em que está sendo empregado. Blumberg e Atre [3] argumentam que no
contexto de bancos de dados relacionais, dados não estruturados são dados que não podem
ser armazenados em linhas e colunas. Em vez disso, os dados devem ser armazenados
num tipo BLOB (binary large object). No contexto de dados gerados e consumidos por
aplicações na Web, dados não estruturados podem ser mensagens, documentos de texto,
apresentações em Power Point, imagens e vídeos. De acordo com Geetha e Mala [12],
dados não estruturados são dados que não possuem um modelo de dados definido e não
oferecem um esquema predefinido de acesso aos dados.
De acordo com Barbulescu et al. [2], email é um exemplo de dado não estrutu-
3.4 Metadados
32
rado. Na caixa de entrada de um mensagem, as informações podem ser organizadas por
data, hora ou tamanho. Se o email fosse totalmente estruturado, seria possível organizar
também por assunto ou conteúdo.
3.4
Metadados
Metadados são considerados "dados sobre dados"[20], [30], ou seja, dados que
descrevem dados. Os metadados descrevem, localizam, explicam um dado, o que torna
possível a recuperação e gerenciamento dos dados [30]. Por exemplo: em um sistema
gerenciador de bancos de dados, se uma pessoa deseja conhecer o domínio, os bancos de
dados criados, as relações em cada banco de dados, deve-se recorrer ao catálogo do banco
de dados, que retornará informações sobre os dados que deseja consultar. McGreal [20]
exemplifica metadados com uma situação do mundo real: uma pessoa precisa encontrar
uma casa em uma cidade, porém, não tem o nome da rua e também o número da casa.
Neste exemplo, o metadado que representa o nome da rua é o atributo logradouro e o
metadado que representa o número da casa é o atributo número. Com base nesses dados,
seria possível encontrar a casa desejada, ou seja, o logradouro e o número do imóvel
descrevem a localização da casa.
Os metadados podem ser classificados em três categorias [30]: (1) metadados
descritivos descrevem recursos com o objetivo de identificar e recuperar informações
através de elementos, tais como: título, autor, palavras-chave; (2) metadados estruturados descrevem como os objetos são compostos e suas relações. Por exemplo: o esquema
do banco de dados [34]; (3) metadados administrativos fornecem informações que auxiliam o gerenciamento de recursos, tais como controle de permissões de acesso, localização
de arquivos [34].
Configuração do banco de dados
Elemento
Valor
Nome do banco de dados Vendas
Nome do usuário
User
Senha
123456
IP do servidor
192.168.1.1
Porta de comunicação
1433
Banco de dados
MSSQL Server
Data da criação
19/11/2011
Tabela 3.5: Exemplo de metadados
A Tabela 3.5 apresenta um exemplo de metadados estruturados, modelo utilizado
neste trabalho. A partir dos dados configurados, é possível identificar que existe uma base
de dados chamada Vendas, que está armazenada no banco de dados Postgresql, e, caso seja
3.5 Arquitetura JDBC
33
necessário se conectar à base de dados, deverá informar o usuário User, a senha 123456 e
a porta de comunicação 1433, ou seja, o conjunto de metadados descreve a maneira para
tornar possível conectar com um banco de dados.
3.5
Arquitetura JDBC
Em uma aplicação que manipula dados originados de várias fontes, a conexão
com os bancos de dados é uma tarefa difícil, pois cada um deles disponibiliza recursos
diferentes para receber as conexões da aplicação, o que torna inviável o estudo de todos
os bancos de dados e a maneira em que é feita a conexão, proporcionando um alto grau
de complexidade no desenvolvimento de aplicações [46]. Nesse contexto, é importante
um mecanismo que ofereça um tipo de conexão padrão com todos os bancos de dados e
assuma as tarefas de realizar as operações.
JDBC (Java Database Connectivity) é uma API desenvolvida na linguagem
Java com o objetivo de executar comandos SQL em bancos de dados [46]. Essa API é
composta de classes, métodos e interfaces Java que são responsáveis por interagir com
a aplicação através de uma linguagem unificada de acesso a dados. Esse conjunto de
elementos é chamado de driver JDBC [44]. Zhang e Zhang [46] argumentam que JDBC
é um mecanismo que estabelece um diálogo entre a aplicação e o banco de dados.
Os drivers JDBC são classificados em quatro categorias, em que cada tipo de
driver contém características e mecanismos diferentes de comunicação com o banco de
dados [46].
Figura 3.12: Tipos de drivers JDBC [46]
A Figura 3.12 apresenta as quatro categorias driver JDBC [46]. Nesse trabalho,
foram utilizados drivers JDBC da quarta categoria.
3.5 Arquitetura JDBC
34
• A primeira categoria consiste de um mecanismo em que são necessários dois
drivers, JDBC e ODBC, para se comunicar com o banco de dados. Nessa categoria,
é necessário instalar bibliotecas locais, o que interfere na portabilidade da aplicação.
• A segunda categoria é composta por parte do programa Java e parte da aplicação
local, e é utilizada para comunicar com o banco de dados cliente. São instalados
drivers específicos nos computadores locais (como driver ODBC), e o driver JDBC
na aplicação transforma as requisições de acesso ao banco de dados no padrão da
API local.
• A terceira categoria é chamada de middleware. Nessa categoria, não é necessário a
instalação de qualquer outro tipo de driver, porém, o driver deve ser instalado no
servidor de banco de dados. O middleware é responsável por realizar as conversões
necessárias para o acesso ao banco de dados.
• A quarta categoria é o driver JDBC Java puro. Nessa categoria, os drivers se comunicam diretamente com o banco de dados, o que proporciona uma independência de
plataforma de desenvolvimento. Assim como na terceira categoria, não é necessário
a instalação de drivers adicionais para a execução de comandos com os bancos de
dados.
Para utilizar a API JDBC em uma aplicação, o desenvolvedor deve, primeiramente, identificar se existe algum driver disponível para o banco de dados utilizado.
Grande parte dos fornecedores de bancos de dados oferecem drivers JDBC a fim de apoiar
a comunicação das aplicações com os bancos de dados. Wiley [44] diz que uma das principais vantagens em utilizar a API JDBC é permitir o acesso a vários bancos de dados,
como MSSQL Server, Oracle, MySQL, sem a necessidade de modificar o código fonte da
aplicação.
A Figura 3.13 apresenta um exemplo em que a API JDBC é utilizada entre a
aplicação e o banco de dados. O núcleo da API JDBC é composto pelo driver JDBC, que
implementa todas as classes e interfaces para conectar e manipular os dados no banco de
dados. Através dos métodos criados no driver JDBC, é construída a conexão para o banco
de dados a ser acessado [44]. A camada driver manager é responsável por gerenciar os
drivers que devem ser utilizados para realizar uma conexão com cada banco de dados
[46].
A API JDBC, quando utilizada pela aplicação, é executada através de três
procedimentos principais [44]: (1) estabelecer a conexão entre a aplicação e o banco de
dados, em que é necessário informar os metadados para realizar a conexão; (2) construir
e executar o comando SQL. Os comandos SQL são construídos na sintaxe padrão SQL,
que é o formato reconhecido pela API; (3) processar os resultados. Após a execução do
comando SQL, a API JDBC recebe o resultado da operação executada pelo banco de
dados no formato de tabela, contendo linhas e colunas.
3.5 Arquitetura JDBC
35
Figura 3.13: Exemplo da arquitetura JDBC [44]
Alguns bancos de dados NOSQL também fornecem driver JDBC [17]. Isso é um
aspecto positivo para resolver parte dos desafios identificados durante a pesquisa, pois, se
tanto os bancos de dados relacionais quanto os bancos de dados NOSQL oferecem driver
JDBC, a aplicação fica responsável por utilizar o driver JDBC do fabricante do banco de
dados.
3.5.1
Driver JDBC para Cassandra
A linguagem de consulta do banco de dados Cassandra, chamada CQL, possui
uma estrutura sintática que se assemelha à linguagem SQL, como foi comentado anteriormente. Entretanto, a semântica implementada na linguagem CQL é diferente da linguagem SQL. Para atender as necessidades do presente trabalho, é importante que a linguagem CQL tenha um comportamento similiar à linguagem SQL, resultando assim em uma
estrutura única de acesso aos dados. O Cassandra fornece uma API JDBC [5], que é uma
extensão da API JDBC padrão, e oferece mecanismos para realizar operações com banco
de dados (conexão com banco de dados, criação de relações, consultas e etc.), utilizando
os recursos que são oferecidos pela arquitetura JDBC, através da sintaxe da linguagem
SQL.
A responsabilidade da API JDBC do Cassandra é realizar o mapeamento para
converter a estrutura da consulta SQL na estrutura da linguagem CQL, fornecer uma
interface unificada de acesso aos dados e permitir enviar uma consulta SQL para o banco
3.5 Arquitetura JDBC
36
de dados Cassandra. As validações de possíveis elementos que podem estar contidos na
consulta SQL, mas que não são reconhecidos pelo Cassandra, é de responsabilidade do
Cassandra. Por exemplo: uma consulta SQL pode conter os elementos left join, top, avg
ou sum. A API JDBC do Cassandra recebe a consulta SQL contendo esses elementos e
envia para o banco de dados. Se não conseguir executar a consulta, será retornado um erro.
Se a consulta for executada com êxito, o resultado é retornado em um objeto Resultset,
componente da API JDBC.
O driver JDBC disponível para o Cassandra recebe atualizações constantes, não
sendo possível afirmar se uma determinada funcionalidade disponível em uma versão
estará disponível em outras versões posteriores. Portanto, as versões do driver JDBC
podem interferir nos resultados obtidos em operações com o banco de dados.
3.5.2
Driver JDBC para MongoDB
O banco de dados MongoDB possui uma estrutura diferente de acesso aos dados
em relação à estrutura da linguagem SQL e da linguagem CQL. Isso se deve ao fato
de possuir uma estrutura diferente da abordagem relacional e da abordagem NOSQL
orientado a colunas. No entanto, é possível encontrar o driver JDBC para o MongoDB
que proporciona um mecanismo de acesso aos dados utilizando a sintaxe SQL [23].
Da mesma maneira como é realizado no banco de dados Cassandra, a responsabilidade do driver JDBC para o MongoDB é mapear a estrutura do comando SQL para
a estrutura do banco de dados MongoDB, possibilitando um mecanismo de acesso unificado aos dados. Ao executar a consulta, o MongoDB tem a responsabilidade de receber
a consulta SQL e validar os atributos e os elementos que foram utilizados na consulta.
Se a consulta for executada com êxito, o resultado é retornado em um objeto Resultset,
que é componente da API JDBC. Se a consulta não for executada com êxito, o banco de
dados retornará uma mensagem informando o motivo pelo qual não foi possível executar
a consulta SQL.
CAPÍTULO 4
Um método para integração de dados
armazenados em bancos de dados relacionais e
NOSQL
Neste capítulo é apresentado um método desenvolvido para integração de dados armazenados em bancos de dados de diferentes abordagens distribuídos em vários
servidores. O método é capaz de executar consultas sem o prévio conhecimento sobre a
localização dos bancos de dados em que estão armazenados os dados.
4.1
Modelo da solução proposta
O presente trabalho define um mecanismo de resolução de consultas inspirado
em [45], em que a partir de uma consulta de entrada escrita nos padrões da linguagem
de consulta SQL, várias outras consultas correspondentes são construídas, sendo uma
para cada relação que compõe a consulta SQL de entrada. Isso se deve ao fato de que as
relações podem estar distribuídas em vários bancos de dados, relacionais e/ou NOSQL.
Sendo assim, as consultas criadas a partir da consulta SQL de entrada são submetidas
separadamente aos respectivos bancos de dados. Os resultados parciais gerados em cada
consulta são armazenados em um único banco de dados relacional temporário, contendo
as relações e atributos de cada consulta. O resultado final é gerado através da submissão
da consulta SQL de entrada no banco de dados relacional temporário.
Ao receber uma consulta SQL, o método não exige o conhecimento prévio dos
bancos de dados nos quais estão armazenados os dados relevantes para o resultado da
consulta de entrada. O método é capaz de identificar os bancos de dados envolvidos na
consulta com base nos elementos da consulta e em metadados previamente cadastrados,
e fornecer meios de executar a operação com os bancos de dados. Além disso, o método
permite executar consultas contendo os seguintes elementos SQL: sum, count, avg, min,
max, group by, order by, having, like, between, in, and, or, join (e suas variações), mesmo
4.2 Estrutura do método
38
se o atributo referenciado em um dos elementos citados estiver armazenado em bancos de
dados NOSQL.
A comunicação com os bancos de dados acessíveis pelo método é realizada por
meio da API JDBC, ou seja, é criado um mecanismo único de acesso aos dados, em
que é utilizado o driver JDBC para acessar os respectivos bancos de dados. Portanto, é
necessário que um banco de dados forneça um driver JDBC para se tornar acessível pelo
método. Em geral, cada banco de dados possui um driver JDBC próprio. A conexão é
estabelecida conforme metadados fornecidos em uma sequência de caracteres de conexão.
Dada uma consulta SQL de entrada, o método pode ser resumido pela sequência
de tarefas abaixo:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
4.2
Identificar a operação.
Identificar as relações.
Identificar os atributos.
Identificar os predicados.
Construir consultas SQL específicas para cada banco de dados.
Identificar os metadados para comunicação com os bancos de dados.
Executar as consultas construídas nos respectivos bancos de dados.
Receber os resultados parciais das consultas executadas nos vários bancos de dados.
Realizar a integração dos dados.
Apresentar o resultado da consulta.
Estrutura do método
O diagrama de fluxo de dados do método proposto é apresentado na Figura
4.1. A consulta SQL inicial, informada no padrão da linguagem de consulta SQL, é
o ponto inicial para o funcionamento do método. A partir da consulta SQL inicial, o
fluxo do método se desenvolve através de quatro fases: Analisar Consulta SQL, Construir
Comandos SQL, Controlar Execução de Consultas SQL e Gerenciar Resultados. Os
depósitos de dados - Elementos SQL, Metadados, Fontes de Dados e Resultados executam tarefas de armazenamento de configurações de conexão, consultas e resultados
parciais e final.
4.2.1
Consulta SQL Inicial
A consulta inicial é o ponto de entrada para a execução do método proposto. A
sintaxe padrão da linguagem de consulta SQL é utilizada para compor uma consulta e
as relações e atributos que podem ser utilizados são descritos no depósito Metadados. A
4.2 Estrutura do método
39
Figura 4.1: Fluxo de dados do método proposto
consulta SQL inicial é construída com base no esquema local, ou seja, nos metadados de
armazenamento configurados.
A Figura 4.2 ilustra um exemplo de consulta SQL de entrada. Caso a consulta
contenha atributos de relações diferentes com nomes iguais, é necessário preceder o nome
do atributo com o nome da relação. Todos os demais componentes da consulta seguem
a sintaxe padrão SQL. É importante notar que nenhuma referência é feita aos bancos de
dados relevantes para a consulta, os quais serão identificados posteriormente através das
relações envolvidas.
Figura 4.2: Exemplo de consulta
4.2.2
Depósitos de dados
Os depósitos de dados são relações criadas em um banco de dados relacional
e são utilizados pelo método para armazenar permanentemente os seguintes dados:
metadados de conexão e metadados de armazenamento. Além disso, são utilizados para
armazenar temporariamente os seguintes dados: a consulta SQL inicial, os elementos SQL
extraídos da consulta SQL inicial, as novas consultas SQL construídas para cada relação
4.2 Estrutura do método
40
da consulta SQL inicial, os resultados parciais obtidos da execução das novas consultas
SQL construídas.
Elementos SQL
No processo de identificação de elementos SQL a partir da consulta inicial, cada
elemento identificado é armazenado temporariamente para ser consumido pelo processo
de construção de comandos SQL. Os elementos da consulta SQL inicial armazenados
neste depósito de dados são: o tipo da operação, a lista de relações referenciadas, a lista
de atributos de cada relação e os predicados específicos de cada relação (um predicado
específico inclui atributos de uma única relação). As consultas construídas para cada
relação da consulta inicial também são armazenadas temporariamente neste depósito,
juntamente com o nome do banco de dados onde cada consulta será executada.
A Figura 4.3 apresenta o diagrama de classe que representa parte das relações
que compoe o depósito Elementos SQL, bem como a estrutura das relações. O diagrama
mostra que uma relação pode conter vários atributos, e que uma relação pode conter vários
predicados (opcionalmente). As relações apresentadas no diagrama de classe são:
Figura 4.3: Relações do depósito Elementos SQL
• Relacoes: mantém temporariamente as relações identificadas na consulta inicial.
• Atributos: mantém temporariamente os atributos de cada relação juntamente com
o nome da relação.
• Predicados: mantém temporariamente o predicado, o operador utilizado para especificar o próximo predicado (and, or, in) e o nome da relação que mantém o atributo
referenciado no predicado.
4.2 Estrutura do método
41
A Figura 4.4 representa outras duas classes que compoe o depósito Elementos
SQL. As relações não possuem relacionamento entre si, pois mantém temporariamente, na
relação Operacao, a palavra que indica a operação realizada e, na relação ComandosSQL,
os novos comandos SQL construídos para cada relação da consulta inicial, juntamente
com o nome da relação.
Os dados armazenados temporariamente nas relações deste depósito de dados
são excluídos após serem executadas todas as fases do método.
Figura 4.4: Outras relações do depósito Elementos SQL
Metadados
O depósito Metadados é implementado em um banco de dados relacional local,
isto é, diretamente acessível pelo método, composto por um conjunto de relações em que
são mantidas informações necessárias para conexão com os bancos de dados acessíveis
pelo método, bem como suas respectivas estruturas de armazenamento (relações e atributos).
A Figura 4.5 apresenta o diagrama de classe que representa as relações que
compõe os metadados de conexão dos bancos de dados utilizados pelo método. O
diagrama mostra que um banco de dados está associado a um único domínio e um domínio
pode conter vários bancos de dados. Um banco de dados pode conter várias relações e uma
relação pode conter vários atributos. A classe Dominio representa o domínio (assunto dos
dados) que são acessíveis pelo método.
Os metadados de conexão devem ser configurados manualmente e são representados pela classe BancosDeDados e incluem, para cada banco de dados:
• Nome do banco de dados, representado pelo atributo NomeBD.
• Categoria (relacional ou NOSQL), representado pelo atributo Categoria.
• O domínio dos dados armazenados, representado pelo atributo IdDominio, que faz
referência ao atributo IdDominio da relação Dominio.
• O nome ou endereço IP do servidor que hospeda o banco de dados, representado
pelo atributo Servidor.
• A porta de comunicação, representado pelo atributo Porta.
• Uma identificação do driver JDBC, representado pelo atributo DriverJDBC.
• Nome de usuário de acesso ao banco de dados, representado pelo atributo Usuario.
4.2 Estrutura do método
42
Figura 4.5: Representação das relações que compõe os metadados
• Senha do usuário, representado pelo atributo Senha.
Os metadados de armazenamento devem ser configurados manualmente e são
representados, na Figura 4.5, pelas relações Relacoes e Atributos, e incluem, para cada
relação:
Relação Relacoes:
• Nome da relação, representado pelo atributo NomeRelacao.
• Nome do banco de dados ao qual pertence, representado pelo atributo IdBanco,
que faz referência ao atributo IdBanco na relação BancosDeDados.
Relação Atributos:
• Conjunto de atributos, representado pelo atributo NomeAtributo.
• Nome da relação a qual pertence, representado pelo atributo IdRelacao, que faz
referência ao atributo IdRelacao na relação Relacoes.
O mecanismo proposto estabelece uma restrição com respeito aos nomes de
relações. Por esta restrição, bancos de dados no mesmo domínio não podem ter relações
com nomes iguais. Para a definição desta regra, os seguintes argumentos são considerados:
informações de um mesmo domínio podem estar armazenadas em diferentes bancos de
4.2 Estrutura do método
43
dados de diferentes categorias; a consulta SQL inicial não faz referência direta aos bancos
de dados, mas utiliza os nomes de relações para identificar os bancos de dados relevantes
para uma consulta.
Para viabilizar uma consulta a bancos de dados de diferentes categorias, no
contexto do mecanismo proposto neste trabalho, a estrutura de um banco de dados
NOSQL deve ser descrita na forma de relações e atributos.
• Mapeamento de um banco de dados orientado a colunas para relacional
O mapeamento de um banco de dados orientado a colunas para relacional deve
ser feito manualmente, no qual o keyspace é representado pelo nome do banco de
dados, uma família de colunas é representada pelo nome da relação, a chave da
coluna é representada por um atributo [1]. A Figura 4.6 exemplifica a estrutura
de um banco de dados orientado a colunas mapeado para a estrutura relacional.
O exemplo ilustra um keyspace denominado Estoque, contendo uma família de
colunas chamada Clientes, em que cada coluna da família de colunas corresponde
a um atributo de cliente e sua representação relacional.
Figura 4.6: Estrutura de um banco de dados orientado a colunas
mapeada para o modelo relacional
• Mapeamento de um banco de dados orientado a documentos para relacional
De modo análogo, o mapeamento de um banco de dados orientado a documentos
para uma estrutura relacional é feito de forma manual e deve ter a seguinte
correspondência: o banco de dados receberá o nome do banco de dados criado para
armazenar a coleção de documentos, uma coleção de documentos é representada
pelo nome da relação, um documento é representado por uma tupla, um atributo
contido no documento é represento por um atributo da relação.
A Figura 4.7 exemplifica o mapeamento da estrutura de um banco de dados
orientado a documentos para a estrutura relacional. A esquerda ilustra uma coleção
de documentos chamada Clientes, na qual cada documento corresponde ao registro
de um cliente, e à direita, a estrutura relacional correspondente.
4.2 Estrutura do método
44
Figura 4.7: Estrutura de um banco de dados orientado a documentos mapeada para o modelo relacional
Fontes de Dados
O depósito Fontes de Dados representa o conjunto de bancos de dados que podem
ser consultados pelo método. Para descrever cada fonte de dados acessível pelo método,
é necessário a configuração de metadados correspondentes, que incluem informações de
conexão e descrição do armazenamento.
Para os metadados de conexão, são mantidas informações que possibilitam
conectar aos bancos de dados, tais como: nome do banco de dados, usuário, senha, porta
de comunicação e uma indicação do driver JDBC do banco de dados. Para os metadados
que descrevem armazenamento, são mantidas informações, tais como: nome de cada
relação, nome dos atributos que compõem as relações e o banco de dados ao qual pertence.
Tais informações são empregadas para gerar e executar consultas nas fontes de dados
consideradas.
Resultados
O depósito Resultados armazena os resultados gerados por cada banco de dados
envolvido na consulta. Para cada relação da consulta, é criada uma relação temporária no
banco de dados local com o mesmo nome e os mesmos atributos da relação da consulta
SQL inicial. A integração dos dados e o retorno do resultado final da consulta são gerados
a partir deste depósito de dados.
Assim como no depósito Elementos SQL, os dados armazenados e as relações
criadas temporariamente neste depósito de dados são excluídos após serem executadas
todas as fases do método.
4.2.3
Analisar Consulta SQL
A função Analisar Consulta SQL corresponde ao procedimento de segmentação
da consulta SQL inicial, para identificar, separadamente, os componentes das cláusulas
4.2 Estrutura do método
45
select, from e where. Cada elemento identificado é armazenado no depósito Elementos
SQL. As tarefas identificar operação, identificar as relações, identificar os atributos e
identificar os predicados, citadas no inicio desta seção, são executadas por esta função.
Ao final do processo de analise da consulta SQL inicial, são armazenados no
depósito Elementos SQL: o tipo da operação, as relações da consulta, e, para cada
relação, sua lista de atributos e seus predicados específicos. Cada par <relação,atributo>
identificado, é validado junto ao depósito Metadados.
A consulta SQL de entrada pode conter elementos na cláusula select e/ou na
cláusula where que não podem ser executados pelos gerenciadores de bancos de dados
NOSQL, tais como: sum, min, max, avg, count, group by, having, between. Assim, a
primeira tarefa executada na fase de análise da consulta SQL inicial consiste em eliminar
os elementos citados, caso existam. Nesta fase, os elementos citados são eliminados
da consulta inicial sem verificar o tipo de banco de dados que está sendo consultado
(relacional ou NOSQL). Os atributos de relacionamentos de cada relação também são
identificados e removidos da consulta SQL inicial.
Figura 4.8: Exemplo de consulta SQL de entrada redefinida
A Figura 4.8 apresenta a mesma consulta exibida na Figura 4.2, porém, a partir da
primeira tarefa na fase de análise da consulta SQL inicial, foram eliminados os atributos
que indicam relacionamentos, pois esses atributos e o relacionamento pode não existir
no banco de dados em que a consulta for executada. Após essa tarefa, o analisador Zql é
utilizado para: identificar a operação realizada, as relações referenciadas, os atributos de
cada relação e os predicados específicos de cada relação.
• Operação: a palavra indicativa da operação realizada é identificada e armazenada
no depósito Elementos SQL.
• Relações: as relações são extraídas e armazenadas no depósito Elementos SQL
• Atributos: os atributos são extraídos em conjunto à relação a qual pertence. Por
exemplo: se o nome do atributo é precedido do nome da relação, é identificado o
par relação e atributo. Caso contrário, é necessária uma consulta no depósito Metadados para identificar a relação que contém o atributo. Cada par <atributo,relação>
identificado é armazenado no depósito Elementos SQL
• Predicados: os predicados são identificados juntamente com a relação que mantém
o atributo referenciado no predicado. Por exemplo: se o atributo é precedido do
4.2 Estrutura do método
46
nome da relação, é identificado o predicado e a relação. Caso contrário, é feita uma
consulta no depósito Metadados para identificar a relação que contém o atributo.
Cada par <predicado,relação> identificado é armazenado no depósito Elementos
SQL
Figura 4.9: Elementos SQL após a análise da consulta SQL
A Figura 4.9 exemplifica o conjunto de elementos SQL identificados e mantidos
temporariamente no depósito Elementos SQL. Os elementos identificados são os mesmos
exemplificados na Figura 4.8.
O algoritmo 1 apresenta os passos que são executados para segmentar a consulta
SQL inicial e identificar cada elemento SQL separadamente.
4.2.4
Construir Comandos SQL
Esta etapa é responsável por construir consultas SQL, uma consulta para cada
relação identificada na consulta SQL inicial. Para tanto, utiliza os elementos da consulta
inicial armazenados no depósito Elementos SQL.
Na consulta SQL de entrada, é necessário informar os atributos de relacionamentos, no caso, rel1.id = rel2.id, pois quando a consulta for executada nos respectivos
bancos de dados e os resultados armazenados temporariamente no depósito Resultados, a
consulta SQL inicial, que contém estes atributos, será executada nesse depósito de dados.
Portanto, o atributo id de ambas as relações deve estar presente nas relações temporárias
do depósito Resultados.
O algoritmo 2 apresenta os passos que são executados para construir consultas
SQL para cada relação envolvida na consulta inicial.
4.2 Estrutura do método
47
Algoritmo 1: Analisar a consulta SQL inicial
Entrada: Consulta SQL inicial
Saída: Operação, relações, atributos e predicados da consulta inicial
inicio
Elimina Elementos
Elimina Predicados
Identifica Operação
Identifica Relações
Identifica Atributo
se Atributo Indica Agregação então
Identifica Atributo
se Precede Relação então
Grava Par Atributo-Relação
fim
senão
Identifica Relação do Atributo
Grava Par Atributo-Relação
fim
fim
senão
se Precede Relação então
Grava Par Atributo-Relação
fim
senão
Identifica Relação do Atributo
Grava Par Atributo-Relação
fim
fim
se Existe Predicado então
se Relacao Precede Atributo então
Grava Predicado
fim
senão
Identifica Relação do Atributo
Grava Predicado
fim
fim
fin
As consultas SQL construídas nesta fase são armazenadas no depósito Elementos
SQL, cada uma com uma referência ao banco de dados objeto da consulta. A Figura
4.10 exemplifica as consultas SQL construídas pelo método a partir da consulta inicial
exemplificada na Figura 4.8. Neste exemplo, o banco de dados BD1 é ilustrado em um
banco de dados relacional e o banco de dados BD2 é ilustrado em um banco de dados
NOSQL.
4.2 Estrutura do método
48
Figura 4.10: Consultas construídas pelo método.
Algoritmo 2: Construir consultas SQL
Entrada: Elementos SQL extraídos da consulta inicial
Saída: Consultas SQL para cada relação da consulta inicial
inicio
Busca Relações no Depósito Elementos SQL
enquanto Existe Relação faça
Identifica Atributos da Relação Atual
Identifica Predicados da Relação Atual
Identifica Bd da Relação Atual
Constrói Consulta SQL
Grava Consulta SQL no Depósito Elementos SQL
fim
fin
4.2.5
Controlar Execução de Consultas SQL
O processo Controlar Execução de Consultas SQL realiza toda a tarefa de envio
das consultas para os bancos de dados referenciados na consulta SQL inicial. Para cada
consulta, são executadas as seguintes tarefas:
1.
2.
3.
4.
5.
6.
Criar relações temporárias no depósito Resultados.
Buscar metadados de conexão com o banco de dados no depósito Metadados.
Estabelecer a conexão com o banco de dados.
Enviar a consulta para execução.
Receber o resultado da consulta.
Armazenar o resultado em uma relação temporária no depósito Resultados.
Para cada consulta são criadas relações temporárias no depósito Resultados a
fim de receber os resultados obtidos em cada consulta executada. As relações são criadas
contendo os atributos de cada relação informados na consulta SQL inicial.
4.2 Estrutura do método
49
As tarefas Estabelecer a conexão com o banco de dados, Enviar a consulta para
execução e Receber o resultado da consulta são realizadas com o apoio do driver JDBC
de cada banco de dados. Para os bancos de dados NOSQL, o próprio driver JDBC tem a
tarefa de traduzir a consulta SQL para o padrão de cada banco de dados NOSQL.
O algoritmo 3 apresenta os passos que são executados para executar as consultas
construídas para cada relação envolvida na consulta inicial e armazenar os resultados
parciais no depósito Resultados.
Algoritmo 3: Executar consultas SQL construídas
Entrada: Comandos SQL construídos para cada relação da consulta inicial
Saída: Resultados parciais obtidos em cada banco de dados
inicio
Busca Relações no Depósito Elementos SQL
enquanto Existir Relação faça
Busca Comando SQL Construído
Busca Metadados da Relação
Busca Metadados de Conexão do Banco de Dados
se Categoria = Coluna então
Executa Consulta Banco de Dados Coluna
Grava Resultado Parcial da Consulta no Depósito Resultados
fim
se Categoria = Documento então
Executa Consulta Banco de Dados Documento
Grava Resultado Parcial da Consulta no Depósito Resultados
fim
se Categoria = Relacional então
Executa Consulta Banco de Dados Relacional
Grava Resultado Parcial da Consulta no Depósito Resultados
fim
fim
fin
4.2.6
Gerenciar Resultados
Este processo executa a consulta SQL de entrada no depósito Resultados utilizando os resultados parciais armazenados. Este processo é exemplificado na Figura 4.11.
A solução adotada permite executar a consulta SQL inicial em um banco de
dados relacional, mesmo que os resultados parciais tenham sido obtidos de bancos de
dados NOSQL. Assim, com os resultados parciais mantidos em um banco de dados
relacional, é possível utilizar todos os recursos que a linguagem SQL oferece, tais como
4.2 Estrutura do método
50
junções, agregações, ordenações e outros recursos não disponíveis em bancos de dados
NOSQL.
Figura 4.11: Consulta inicial executada no depósito Resultados
4.2.7
Exemplo passo a passo
Dada uma consulta inicial: select IdVenda, DataVenda, Vendas.IdCliente,
Cliente.IdCliente, TotalVenda, Nome, Endereco from Vendas, Cliente where Vendas.IdCliente = Cliente.IdCliente and DataVenda = 22/05/2013 and Nome = Pedro, em
que a relação Vendas está armazenada em um banco de dados NOSQL orientado a colunas e a relação Cliente está armazenada em um banco de dados relacional, os passos que
são executados para obter o resultado final são:
• Passo 1:
Objetivo: eliminar os elementos que não são reconhecidos pelo analisador Zql e
atributos de relacionamentos.
Resultado: select IdVenda, DataVenda, Vendas.IdCliente, Cliente.IdCliente, TotalVenda, Nome, Endereco from Vendas, Cliente where DataVenda = 22/05/2013 and
Nome = Pedro.
• Passo 2:
Objetivo: identificar a operação, relações, atributos e predicados da consulta inicial
e armazenar temporariamente no depósito Elementos SQL.
Resultado: elementos SQL identificados separadamente. O resultado do passo 2 é
ilustrado nas tabelas 4.1 e 4.2.
Relação
Atributos
Predicado
Vendas
IdVenda, IdCliente, DataVenda, TotalVenda
DataVenda = 22/05/2013
Tabela 4.1: Relações, atributos e predicados da relação Vendas.
• Passo 3:
Objetivo: construir novas consultas SQL, sendo uma para cada relação envolvida na
4.2 Estrutura do método
Relação
Atributos
Predicado
51
Cliente
IdCliente, Nome e Endereco
Nome = Pedro
Tabela 4.2: Relações, atributos e predicados da relação Cliente.
consulta inicial, compostas pelos atributos e predicados específicos de cada relação.
Resultado: consultas construídas para cada relação envolvida na consulta inicial. O
resultado do passo 3 é ilustrado na Tabela 4.3.
Consulta 1
Consulta 2
select IdVenda, IdCliente, DataVenda, TotalVenda from Vendas
where DataVenda = 22/05/2013
select IdCliente, Nome, Endereco from Cliente where Nome =
Pedro
Tabela 4.3: Consultas SQL construídas para cada relação.
• Passo 4:
Objetivo: executar cada consulta nos respectivos bancos de dados separadamente,
criar relações temporárias no depósito Resultados e armazenar os resultados parciais temporariamente.
Resultado: relações Cliente e Vendas criadas temporariamente no depósito Resultados. O resultado é ilustrado nas tabelas 4.4 e 4.5.
Relação Cliente
IdCliente Nome
2
Pedro
Endereco
Rua 12, n54
Tabela 4.4: Relação Cliente criada no depósito Resultados.
Relação Vendas
IdVenda
IdCliente
DataVenda
TotalVenda
1
2
22/05/2013
150.00
25
2
22/05/2013
95.00
33
2
22/05/2013
50.00
Tabela 4.5: Relação Vendas criada no depósito Resultados.
• Passo 5:
Objetivo: executar a consulta inicial no depósito Resultados.
Resultado: dados solicitados na consulta inicial retornados do depósito Resultados.
O resultado do passo 5 é ilustrado na Tabela 4.6.
4.2 Estrutura do método
52
Resultado da consulta inicial
IdVenda
DataVenda
IdCliente IdCliente TotalVenda Nome
Endereco
1
22/05/2013
2
2
150.00
Pedro
Rua 12, n54
25
22/05/2013
2
2
95.00
Pedro
Rua 12, n54
33
22/05/2013
2
2
50.00
Pedro
Rua 12, n54
Tabela 4.6: Resultado da consulta inicial executada no depósito
Resultados.
• Passo 6:
Objetivo: eliminar todas as relações temporarias criadas no passo 4 e todos os elementos SQL identificados no passo 2.
Resultado: relações criadas no passo 4 excluídas do depósito Resultados. Elementos SQL identificados no passo 2 eliminados do depósito Elementos SQL.
Os passos apresentados anteriormente aplicam todos os processos descritos do
método proposto. É importante destacar que, na consulta SQL inicial, alguns atributos foram solicitados precedendo o nome da relação, pois existem, na mesma consulta, atributos
com o mesmo nome. Portanto, é necessário informar qual relação mantém o respectivo
atributo. Entretanto, outros atributos não foram precedidos pelo nome da relação. Neste
caso, o método é capaz de identificar através dos metadados de armazenamento a relação
que mantém um determinado atributo.
A partir da apresentação do método proposto, é possível definir como principal
contribuição deste trabalho, acessar vários bancos de dados através de uma única consulta
escrita na linguagem de consulta SQL, mesmo em bancos de dados NOSQL, que,
nativamente, não suporta tal linguagem de consulta. Além disso, é possível executar
consultas contendo os seguintes elementos: sum, count, min, max, avg, group by, having,
order by, join, between, like, in, or, and, mesmo que as relações e atributos estejam
armazenados em bancos de dados NOSQL.
CAPÍTULO 5
Um protótipo para avaliar o método de
integração de dados
Para demonstrar a viabilidade do método proposto neste trabalho, um protótipo
foi desenvolvido. Nesta seção estão descritas sua estrutura, seus requisitos funcionais e
não funcionais, os desafios encontrados durante o seu desenvolvimento, as configurações
realizadas para permitir o funcionamento do protótipo e os resultados obtidos com a
execução do protótipo.
Diante do contexto apresentado no Capítulo 1, dos trabalhos relacionados ao
assunto de integração de dados no Capítulo 2 e do método apresentado no Capítulo 4, os
objetivos do protótipo são:
• Permitir a experimentação do método proposto através de consultas escritas no
padrão da linguagem de consulta SQL, contendo elementos que não são executados
de forma nativa pelos bancos de dados NOSQL, tais como: sum, count, min, max,
avg, join, group by, order by, having, like, or, in, and.
5.1
Desafios encontrados durante o desenvolvimento
Durante o desenvolvimento do protótipo, alguns desafios foram superados, entre
eles, estão:
• Cada categoria de bancos de dados NOSQL oferece recursos diferentes na manipulação de dados, além de serem diferentes da abordagem relacional, motivos pelos
quais tornou difícil encontrar um mecanismo padrão de acesso aos dados.
• Encontrar um ambiente real que utiliza as duas abordagens de bancos de dados para
aplicar o método proposto.
• Encontrar um driver JDBC para cada banco de dados NOSQL.
5.2 Requisitos do protótipo
5.2
54
Requisitos do protótipo
Os requisitos funcionais são as especificações do que o sistema deve fornecer, de
como o sistema deve reagir à entradas específicas [36]. Por exemplo: cadastro de produtos,
cadastro de clientes, registro de vendas e etc.
O protótipo deve fornecer meios de inserir uma consulta no padrão da linguagem
SQL e um mecanismo de visualização do resultado final da consulta. Após o término da
consulta, o protótipo deve estar preparado para uma nova consulta. Além disso, deve
permitir as configurações de metadados necessários para executar uma consulta, tais
como: metadados de conexão dos bancos de dados acessíveis ao protótipo, domínios,
relações, atributos e predicados. A tabela 5.1 apresenta os requisitos funcionais do
protótipo.
Requisito
RF1
RF2
RF3
RF4
RF5
RF6
RF7
Descrição
Os metadados de conexão dos bancos de dados disponíveis devem
ser configurados.
Devem ser configurados os metadados de armazenamento, tais
como: relações, atributos, predicados e domínios.
Deve haver meios de se inserir uma consulta no padrão da linguagem SQL.
O protótipo deve acessar os bancos de dados envolvidos na consulta SQL inicial, e, para isso, utilizar os metadados de conexão
previamente configurados.
O protótipo deve construir novas consultas SQL, uma para cada
relação identificada na consulta SQL inicial.
As novas consultas devem ser executadas em seus respectivos
bancos de dados.
Os resultados parciais gerados em cada banco de dados devem ser
integrados em apenas um resultado final.
Tabela 5.1: Tabela de requisitos funcionais do protótipo
Requisitos não funcionais são restrições aos serviços ou funções oferecidos pelo
sistema [36]. Por exemplo: se um sistema funciona em rede ou não, quais bancos de
dados utilizados, tempo máximo de consulta e etc. A tabela 5.2 apresenta os requisitos
não funcionais do protótipo.
Requisito
RNF1
Descrição
O protótipo deve ser capaz de executar consultas em bancos de
dados relacionais e NOSQL
Tabela 5.2: Tabela de requisitos não funcionais do protótipo
5.3 Descrição do protótipo
5.3
55
Descrição do protótipo
Nesta seção são descritas as tecnologias utilizadas no desenvolvimento do protótipo e as telas disponíveis para realizar as configurações no protótipo.
5.3.1
Tecnologias utilizadas
Para o desenvolvimento do protótipo foram utilizadas as seguintes ferramentas:
Java 7.13 como linguagem de programação, NetBeans 8.0.1 como IDE de desenvolvimento, sistema operacional Windows 7 Ultimate, banco de dados MSSQL Server Express,
Astah Professional para criação dos diagramas.
5.3.2
Funcionalidades do protótipo
O protótipo foi desenvolvido com características desktop, isto é, deve ser instalado em computadores distribuídos em uma rede, não sendo necessário a utilização de
browsers para sua execução. A Figura 5.1 apresenta a tela inicial do protótipo.
Figura 5.1: Tela inicial do protótipo
No estágio de desenvolvimento atual, o protótipo fornece as seguintes funcionalidades para cadastramento de metadados.
• Cadastrar BD: opção disponível para configurar os bancos de dados acessíveis no
protótipo, bem como seus metadados de conexão.
• Cadastrar Relações: opção disponível para configurar as relações que compõe um
bancos de dados.
• Cadastrar Atributos: opção disponível para configurar os atributos de cada relação.
5.3 Descrição do protótipo
56
• Cadastrar Domínios: opção disponível para cadastrar os domínios da aplicação.
A Figura 5.2 apresenta a tela de cadastro dos metadados de conexão de bancos
de dados.
Figura 5.2: Tela de cadastro metadados de conexão
As opções disponíveis são:
• Servidor: nome ou endereço IP do servidor no qual está instalado o banco de dados.
A porta de comunicação com o banco de dados deve ser informada posteriormente
precedida do sinal de dois pontos (:).
• Domínio: nome do domínio em que o banco de dados está contido.
• Driver JDBC: representação do driver JDBC do banco de dados.
• Classe BD: representação da classe do driver JDBC do banco de dados.
• Nome do banco de dados: nome do banco de dados.
• Usuário: usuário de acesso ao banco de dados.
• Senha: senha de acesso ao banco de dados.
• Categoria: nome indicativo da categoria do banco de dados (Coluna, para bancos
de dados orientado a colunas, Documento, para bancos de dados orientado a
documentos, e Relacional, para bancos de dados relacionais).
• SGBD: nome do SGBD.
A Figura 5.3 apresenta a tela de cadastro de relações.
As opções disponíveis são:
• Relação: nome da relação.
5.3 Descrição do protótipo
57
Figura 5.3: Tela de cadastro de relações
Figura 5.4: Tela de cadastro de atributos
• Nome do banco de dados: nome do banco de dados na qual a relação está contida.
A Figura 5.4 apresenta a tela de cadastro de atributos.
As opções disponíveis são:
• Atributo: nome do atributo.
• Relação: nome da relação no qual o atributo está contido.
A Figura 5.5 apresenta a tela de cadastro de domínios.
A opção disponível é:
• Domínio: indica o nome do domínio que o protótipo será executado.
5.4 Resultados obtidos
58
Figura 5.5: Tela de cadastro de domínios
Em todas as telas do protótipo são disponibilizados alguns componentes em
comum:
• Uma tabela na qual estão contidos todos os cadastrados.
• Botão Novo, que permite limpar os componentes de texto, gerar um novo Id para o
cadastro e iniciar um novo registro.
• Botão Salvar, que permite salvar os dados informados.
• Botão Alterar, que permite alterar um registro cadastrado.
• Botão Excluir, que permite excluir um registro.
• Campo Id, que tem a tarefa de manter a integridade dos dados, contendo um valor
único para cada registro, sendo gerado automaticamente pelo protótipo.
5.4
Resultados obtidos
Devido à dificuldade de encontrar um banco de dados público com as características desejadas para esse trabalho, ou seja, com dados distribuídos em bancos de dados
relacionais e NOSQL, foi necessário criar alguns bancos de dados de exemplo para aplicar o método proposto. Os bancos de dados apresentados nesta seção são considerados de
pequeno porte e utilizados apenas para o experimento, motivo pelo qual, aspectos como
escalabilidade, desempenho e tempo de consulta não foram considerados nos experimentos. Por este motivo, o objetivo dos experimentos é validar o método proposto executando
consultas escritas no padrão da linguagem de consulta SQL em bancos de dados relacionais e NOSQL, contendo elementos não executados de forma nativa pelos bancos de
dados NOSQL.
Como explicado no Capítulo 3, bancos de dados NOSQL não permitem relacionamentos. Entretanto, para ilustrar o domínio e as famílias de colunas, coleções de
5.4 Resultados obtidos
59
documentos e relações criadas para executar os experimentos, foram criados diagramas
de classe, e em alguns diagramas, contendo a indicação de relacionamentos, porém, esses
relacionamentos são realizados na aplicação.
5.4.1
Ambiente dos experimentos
O protótipo implementado é composto por elementos que precisam ser configurados para alcançar os objetivos propostos pelo método. A seguir são apresentadas as
configurações dos metadados de conexão dos bancos de dados acessíveis pelo protótipo,
bem como os metadados de armazenamento de cada relação.
Nome BD
BDVendas
Categoria
Coluna
Domínio
Varejista
Servidor
localhost
Porta
9160
CondPag
Documento
Varejista
localhost
27017
BDDados
Relacional
Varejista
FLAVIOFAV
1433
Documento
Varejista
localhost
27017
Relacional
Varejista
localhost
5432
Documento
Varejista
localhost
27017
Clientes
BDFuncionarios
Fornecedor
JDBC
jdbc:
cassandra
jdbc:
mongo
jdbc:
sqlserver
jdbc:
mongo
jdbc:
postgresql
jdbc:
mongo
Usuario Senha
FAV
123
postgres fav123
Tabela 5.3: Configuração dos metadados de conexão no depósito
Metadados
A Tabela 5.3 apresenta a configuração dos metadados de conexão dos bancos de
dados acessíveis pelo protótipo.
O domínio criado para aplicar o método proposto corresponde a uma empresa
fictícia de vendas e mantém informações sobre vendas efetuadas, tais como: número da
venda, data da venda, nome do cliente, produtos vendidos e outros dados referentes às
vendas. As consultas podem solicitar, por exemplo, informações sobre as vendas efetuadas
em um período de tempo, a média das vendas entre um mês e outro, as compras efetuadas
por um determinado cliente, além de outros tipos de consultas.
A Tabela 5.4 apresenta as relações, coleções de documentos e famílias de colunas
criadas em bancos de dados relacionais e em bancos de dados NOSQL a fim de realizar os
experimentos. Foi criado um keyspace no banco de dados Cassandra chamado BDVendas,
e nele foram criadas duas famílias de colunas, Vendas e ItensVenda. Foram criados
três bancos de dados no banco de dados MongoDB: Fornecedor, e criada também uma
5.4 Resultados obtidos
SGBD
Cassandra
MongoDB
MongoDB
MongoDB
MSSQL Server
Postgresql
Categoria
Coluna
Documento
Documento
Documento
Relacional
Relacional
60
Nome Banco
BDVendas
Fornecedor
Clientes
CondPag
BDDados
BDFuncionarios
Repositórios
Vendas, ItensVenda
Fornecedor
Clientes
CondPag
Produto, EntradaNFe, ItensEntrada
Funcionarios
Tabela 5.4: Conjunto de relações, coleções de documentos e famílias de colunas para os experimentos.
coleção de documentos chamada Fornecedor; Clientes, e criada também uma coleção de
documentos chamada Clientes; CondPag, e criada também uma coleção de documentos
chamada CondPag. No banco de dados MSSQL Server foi criado um banco de dados
chamado BDDados com as seguintes relações: Produto, EntradaNFe e ItensEntrada. No
banco de dados Postgresql foi criado um banco de dados chamado BDFuncionarios com
a relação Funcionarios.
A Figura 5.6 apresenta o diagrama de classe que representa as famílias de colunas
criadas no banco de dados Cassandra. O diagrama apresenta uma relação de composição
entre as relações Vendas e ItensVenda, na qual só haverá itens de venda se existir uma
venda relacionada aos itens, e uma venda pode conter vários itens de venda.
Figura 5.6: Famílias de colunas criadas no banco de dados Cassandra.
Os objetivos da família de colunas Vendas são armazenar informações sobre as
vendas, tais como:
• Número da venda, representado pelo atributo IdVenda.
• O cliente que efetuou a compra, representado pelo atributo IdCliente.
• A condição de pagamento utilizada para faturar a venda, representado pelo atributo
IdCondPag.
• O vendedor que efetivou a venda, representado pelo atributo IdFuncionario.
• A data em que a venda foi efetuada, representada pelo atributo DataVenda.
A família de colunas ItensVenda é responsável por armazenar os itens (produtos)
que são gerados para cada venda e outras informações, tais como:
5.4 Resultados obtidos
61
•
•
•
•
Número da venda, representado pelo atributo IdVenda.
O produto vendido, representado pelo atributo IdProduto.
O preço de venda do produto, representado pelo atributo PrecoUnitario.
A quantidade vendida de um determinado produto, representada pelo atributo
Quantidade.
• O valor total do produto, que é o preço de venda multiplicado pela quantidade,
representado pelo atributo SubTotal.
Figura 5.7: Coleção de documentos Clientes criada no banco de
dados MongoDB.
A Figura 5.7 apresenta o diagrama de classe criado para representar a coleção
de documentos criada no banco de dados MongoDB chamada Clientes. A coleção de
documentos Clientes é responsável por armazenar dados referentes aos clientes, tais
como:
•
•
•
•
•
O número que identifica o cliente, representado pelo atributo IdClienteC.
O nome do cliente, representado pelo atributo Nome.
O endereço do cliente, representado pelo atributo Endereco.
A cidade do cliente, representado pelo atributo Cidade.
O telefone do cliente, representado pelo atributo Telefone.
Figura 5.8: Coleção de documentos Fornecedor criada no banco
de dados MongoDB.
A Figura 5.8 apresenta o diagrama de classe criado para representar a coleção
de documentos criada no banco de dados MongoDB chamado Fornecedor. A coleção de
5.4 Resultados obtidos
62
documentos Fornecedor é responsável por armazenar dados referentes aos fornecedores,
tais como:
•
•
•
•
•
O número que identifica o fornecedor, representado pelo atributo IdFornecedor.
O nome do fornecedor, representado pelo atributo RazaoSocial.
O CNPJ do fornecedor, representado pelo atributo Cnpj.
O endereço do fornecedor, representado pelo atributo Endereco.
A cidade do fornecedor, representada pelo atributo Cidade.
Figura 5.9: Coleção de documentos CondPag criada no banco de
dados MongoDB.
A Figura 5.9 apresenta o diagrama de classe criado para representar a coleção
de documentos criada no banco de dados MongoDB chamada CondPag. A coleção de
documentos CondPag é responsável por armazenar dados referentes às condições de
pagamento disponíveis, tais como:
• O número que identifica a condição de pagamento, representado pelo atributo
IdCondPag.
• A descrição da condição de pagamento, representada pelo atributo DescricaoCP.
A Figura 5.10 apresenta o diagrama de classe criado para representar as relações
criadas no banco de dados MSSQL Server. O diagrama apresenta um relacionamento
de composição entre as relações EntradaNFe e ItensEntrada, em que só haverá itens
de entrada se houver uma entrada relacionada aos itens, e uma relação de agregação
entre as relações ItensEntrada e Produto, em que cada item da entrada tem um produto
relacionado, e poderá haver produtos cadastrados mesmo se não houver entradas.
A relação EntradaNFe é responsável por armazenar as informações principais
das entradas de notas fiscais, tais como:
• Número de identificação da entrada, representado pelo atributo IdEntrada.
• O fornecedor no qual os produtos foram comprados, representado pelo atributo
IdFornecedor.
• O funcionário que efetuou a compra, representado pelo atributo IdFuncionario.
• A data em que foi dada a entrada da nota fiscal, representada pelo atributo DataEntrada.
5.4 Resultados obtidos
63
Figura 5.10: Relações criadas no banco de dados MSSQL Server.
• O valor total da nota fiscal, representado pelo atributo ValorTotal.
A relação ItensEntrada é responsável por armazenar as informações dos itens
(produtos) das entradas de notas fiscais, tais como:
•
•
•
•
•
Número de identificação da entrada, representado pelo atributo IdEntrada.
O produto comprado, representado pelo atributo IdProduto.
O valor de compra do produto, representado pelo atributo ValorCompra.
A quantidade comprada, representada pelo atributo Quantidade.
O valor total do produto, que é o preço de compra multiplicado pela quantidade,
representado pelo atributo SubTotal.
A relação Produto é responsável por armazenar as informações dos produtos
disponíveis para serem comprados ou vendidos, tais como:
•
•
•
•
Número de identificação do produto, representado pelo atributo IdProduto.
O nome (descrição) do produto, representado pelo atributo Descricao.
O preço de venda do produto, representado pelo atributo PrecoVenda.
A quantidade disponível em estoque, representado pelo atributo QtdEstoque
A Figura 5.11 apresenta o diagrama de classe criado para representar a relação
criada no banco de dados Postgresql. O diagrama apresenta a classe Funcionarios, na qual
armazena informações sobre os funcionários (vendedores, atendentes e etc.), tais como:
5.4 Resultados obtidos
64
Figura 5.11: Relação Funcionarios criada no banco de dados
Postgresql.
•
•
•
•
•
•
Número de identificação do funcionário, representado pelo atributo IdFuncionario.
O nome do funcionário, representado pelo atributo NomeFuncionario.
A comissão do funcionário, representado pelo atributo Comissao.
O endereço do funcionário, representado pelo atributo Endereco.
A cidade do funcionário, representada pelo atributo Cidade.
O salário do funcionário, representado pelo atributo Salario.
Para ilustrar todo o domínio e a maneira como as consultas foram executadas, foi
criado um diagrama de classe contendo todas as relações, famílias de colunas e coleções
de documentos utilizadas no domínio. A Figura 5.12 apresenta o diagrama de classe e a
seguinte estrutura:
Figura 5.12: Relações utilizadas no experimento
• A família de colunas Vendas se relaciona:
5.4 Resultados obtidos
65
– com a família de colunas ItensVenda através do atributo IdVenda.
– com a coleção de documentos Clientes através do atributo IdCliente.
– com a coleção de documentos CondPag através do atributo IdCondPag.
• A família de colunas ItensVenda se relaciona:
– com a relação Produto através do atributo IdProduto.
• A relação EntradaNFe se relaciona:
– com a relação Funcionarios através do atributo IdFuncionario.
– com a coleção de documentos Fornecedor através do atributo IdFornecedor.
– com a relação ItensEntrada através do atributo IdEntrada.
• A relação ItensEntrada se relaciona:
– com a relação Produto através do atributo IdProduto.
Para realizar os experimentos, foram utilizados os bancos de dados relacionais
MSSQL Server 2008 Express e Postgresql 9.3, e os bancos de dados NOSQL Cassandra
2.1.2, da categoria orientado a colunas, e MongoDB 2.4.5, da categoria orientado a documentos. Os experimentos foram executados em um computador Dell Inspiron N5110,
processador Intel core i5, memória DDR3 de 6 GB, HD de 500 GB. Os bancos de dados
que armazenam as relações que compõe os metadados de conexão e de armazenamento,
bem como o depósito Resultados foram criados no banco de dados MSSQL Server 2008
Express.
A escolha pelo banco de dados MSSQL Server e Postgresql da categoria relacional se justifica pelo amplo material de apoio aos desenvolvedores, por ser um banco de
dados utilizado por grande parte das aplicações existentes, e, por ser classificado como relacional, oferece todos os recursos que a abordagem proporciona. A opção pelo Cassandra
como banco de dados NOSQL orientado a colunas se justifica por ser o banco de dados
da categoria NOSQL que mais se assemelha à abordagem relacional. O banco de dados
MongoDB foi escolhido devido a sua particularidade em armazenar os dados no formato
de documentos, e, por esse motivo, é um desafio encontrar um mecanismo que permita a
integração das três abordagens, relacional, orientado a colunas e orientado a documentos
na mesma aplicação. Uma justificativa que se aplica a todos os bancos de dados é que
ambos fornecem a API JDBC.
Várias consultas foram elaboradas contendo os seguintes elementos SQL: sum,
min, max, avg, count, join (e suas variações), group by, having, order by, between, in, and,
or, like, <, >, <=, >=. Além desses critérios, as consultas foram elaboradas para avaliar
diferentes situações em relação à distribuição dos dados nos bancos de dados disponíveis.
As consultas exemplificadas contêm relações e atributos dos diferentes bancos de dados
utilizados nos experimentos, nas seguintes combinações:
5.4 Resultados obtidos
•
•
•
•
•
•
•
•
•
•
66
Cassandra e MongoDB.
Cassandra, MongoDB e MSSQL Server.
Cassandra, MongoDB e Postgresql.
Cassandra, MongoDB, MSSQL Server e Postgresql.
Cassandra e Postgresql.
Cassandra e MSSQL Server.
MSSQL Server e MongoDB.
Cassandra, MSSQL Server e Postgresql.
Somente Cassandra.
MSSQL Server e Postgresql.
Figura 5.13: Ambiente dos experimentos
A Figura 5.13 apresenta um exemplo do ambiente em que uma aplicação se
comunica com os bancos de dados MSSQL Server, Postgresql, Cassandra e MongoDB.
Esse ambiente pode representar uma empresa do ramo varejista, acadêmico, industrial e
outros tipos de empresas que lidam com dados distribuídos em diferentes fontes de dados.
5.4.2
Exemplos de consultas
Os exemplos de consultas apresentados nesta seção foram elaborados considerando as várias formas de se construir uma consulta SQL. Foram construídas consultas
SQL envolvendo os quatro bancos de dados utilizados nos experimentos, mas não necessariamente utilizados ao mesmo tempo em todas as consultas. A cada exemplo apresentado, são informados quais bancos de dados foram utilizados.
5.4 Resultados obtidos
67
Consultas envolvendo apenas bancos de dados relacionais
Consulta 1: exemplo de consulta que acessa apenas um banco de dados relacional.
• Objetivo da consulta: apresentar todas as entradas de notas fiscais entre os dias
01/01/2015 e 01/05/2015.
• Relações utilizadas: EntradaNFe, ItensEntradaNFe.
• Banco de dados utilizado: MSSQL Server.
• Recursos SQL: inner join para junção, between para intervalo de datas, group by
para agrupamento e order by para ordenação.
O comando SQL correspondente à Consulta 1 é apresentado na Figura 5.14 e o
resultado da consulta é apresentado na Figura 5.15.
Figura 5.14: Exemplo - Consulta 1
Figura 5.15: Resultado da Consulta 1
Consulta 2: exemplo de consulta que acessa dois bancos de dados relacionais.
5.4 Resultados obtidos
68
• Objetivo da consulta: apresentar todas as entradas de notas fiscais entre os dias
01/01/2015 e 01/05/2015 e mostrar o funcionário que efetuou a venda, bem como
o nome do produto.
• Relações utilizadas: EntradaNFe, ItensEntradaNFe, Produto e Funcionários.
• Bancos de dados utilizados: MSSQL Server e Postgresql.
• Recursos SQL: inner join para junção, operadores >= e <= para intervalo de datas,
group by para agrupamento e order by para ordenação.
O comando SQL correspondente à Consulta 2 é apresentado na Figura 5.16 e o
resultado da consulta é apresentado na Figura 5.17.
Figura 5.16: Exemplo - Consulta 2
Figura 5.17: Resultado da Consulta 2
Consultas envolvendo apenas bancos de dados NOSQL
Sabe-se que os bancos de dados NOSQL não oferecem a utilização de determinados operadores, tais como: join, between group by, avg, min, max, sum e outros
5.4 Resultados obtidos
69
operadores. Entretanto, para demonstrar que a partir do método proposto é possível viabilizar essa necessidade, nesta seção serão apresentadas várias consultas SQL contendo
elementos que não são reconhecidos, de forma nativa, pelos bancos de dados NOSQL.
Consulta 3: exemplo de consulta que acessa dois bancos de dados NOSQL.
• Objetivo da consulta: apresentar todas as vendas efetuadas entre os dias
01/02/2015 e 01/05/2015 agrupadas por data da venda e cliente.
• Relações utilizadas: Vendas, Clientes e CondPag.
• Bancos de dados utilizados: Cassandra e MongoDB.
• Recursos SQL: atributos de cada relação que indicam relacionamento, between
para especificar o intervalo de datas, as para criação de alias, sum para somatório
de campos númericos, group by para agrupamento e order by para ordenação.
O comando SQL correspondente à Consulta 3 é apresentado na Figura 5.18 e o
resultado da consulta é apresentado na Figura 5.19.
Figura 5.18: Exemplo - Consulta 3
Figura 5.19: Resultado da Consulta 3
5.4 Resultados obtidos
70
Consulta 4: exemplo de consulta que acessa dois bancos de dados NOSQL.
• Objetivo da consulta: apresentar a quantidade das vendas efetuadas, agrupadas por
data da venda e cliente, das vendas efetuadas entre os dias 01/01/2015 e 01/07/2015.
• Relações utilizadas: Vendas, ItensVenda, Clientes e CondPag.
• Bancos de dados utilizados: Cassandra e MongoDB.
• Recursos SQL: inner join para junção, between para intervalo entre datas, count
para contagem, as para criar de alias, group by para agrupamento, having para filtrar
pelo resultado do campo agrupado e order by para ordenação.
O comando SQL correspondente à Consulta 4 é apresentado na Figura 5.20 e o
resultado da consulta é apresentado na Figura 5.21.
Figura 5.20: Exemplo - Consulta 4
Figura 5.21: Resultado da Consulta 4
Consulta 5: exemplo de consulta que acessa apenas um banco de dados NOSQL.
5.4 Resultados obtidos
71
• Objetivo da consulta: apresentar a média do valor total de vendas, agrupadas por
data da venda, das vendas efetuadas entre os dias 01/03/2015 e 01/06/2015.
• Relações utilizadas: Vendas, ItensVenda.
• Bancos de dados utilizados: Cassandra.
• Recursos SQL: inner join para junção, operadores >= e <= para intervalo de datas,
avg para média, group by para agrupamento e order by para ordenação.
O comando SQL correspondente à Consulta 5 é apresentado na Figura 5.22 e o
resultado da consulta é apresentado na Figura 5.23.
Figura 5.22: Exemplo - Consulta 5
Figura 5.23: Resultado da Consulta 5
Consulta 6: exemplo de consulta que acessa dois bancos de dados NOSQL.
• Objetivo da consulta: apresentar o valor mínimo, agrupado por data da venda, dos
produtos vendidos para a cliente Larissa de Assis Vilela entre os dias 01/03/2015 e
01/08/2015.
5.4 Resultados obtidos
72
• Relações utilizadas: Vendas, ItensVenda e Clientes.
• Bancos de dados utilizados: Cassandra e MongoDB.
• Recursos SQL: inner join para junção, between para intervalo de datas, as para
criação de alias, min para calcular o valor mínimo, group by para agrupamento e
order by para ordenação.
O comando SQL correspondente à Consulta 6 é apresentado na Figura 5.24 e o
resultado da consulta é apresentado na Figura 5.25.
Figura 5.24: Exemplo - Consulta 6
Figura 5.25: Resultado da Consulta 6
Consulta 7: exemplo de consulta que acessa dois bancos de dados NOSQL.
• Objetivo da consulta: apresentar o valor máximo, agrupados por data da venda,
dos produtos vendidos para todos os clientes, exceto para a cliente Larissa de Assis
Vilela, a partir do dia 01/05/2015.
5.4 Resultados obtidos
73
• Relações utilizadas: Vendas, ItensVenda e Clientes.
• Bancos de dados utilizados: Cassandra e MongoDB.
• Recursos SQL: inner join para junção, operadores >= para intervalo de datas, as
para criação de alias, max para calcular o valor máximo, group by para agrupamento
e order by para ordenação.
O comando SQL correspondente à Consulta 7 é apresentado na Figura 5.26 e o
resultado da consulta é apresentado na Figura 5.27.
Figura 5.26: Exemplo - Consulta 7
Figura 5.27: Resultado da Consulta 7
Consulta 8: exemplo de consulta que acessa dois bancos de dados NOSQL.
• Objetivo da consulta: apresentar a média de vendas, agrupadas por data da venda,
das vendas efetuadas entre os dias 01/03/2015 e 30/07/2015 de todos os clientes
cujo o nome comece com a letra L.
5.4 Resultados obtidos
74
• Relações utilizadas: Vendas e Clientes.
• Bancos de dados utilizados: Cassandra e MongoDB.
• Recursos SQL: inner join para junção, operadores >= e <= para intervalo de
datas, as para criação de alias, avg para calcular o valor médio, like para textos
aproximados, group by para agrupamento e order by para ordenação.
O comando SQL correspondente à Consulta 8 é apresentado na Figura 5.28 e o
resultado da consulta é apresentado na Figura 5.29.
Figura 5.28: Exemplo - Consulta 8
Figura 5.29: Resultado da Consulta 8
Consultas envolvendo bancos de dados relacionais e bancos de dados NOSQL
Consulta 9: exemplo de consulta que acessa um banco de dados relacional e um
banco de dados NOSQL.
5.4 Resultados obtidos
75
• Objetivo da consulta: apresentar as vendas efetuadas cujo número da venda,
representado pelo atributo IdVenda, seja igual a 1, 2, 3 ou 4.
• Relações utilizadas: Vendas, ItensVenda e Produto.
• Bancos de dados utilizados: Cassandra e MSSQL Server.
• Recursos SQL: inner join para junção, o operador in para especificar o intervalo
de números e order by para ordenação.
O comando SQL correspondente à Consulta 9 é apresentado na Figura 5.30 e o
resultado da consulta é apresentado na Figura 5.31.
Figura 5.30: Exemplo - Consulta 9
Figura 5.31: Resultado da Consulta 9
Consulta 10: exemplo de consulta que acessa dois bancos de dados relacionais
e um banco de dados NOSQL.
• Objetivo da consulta: apresentar a somatória da quantidade de produtos vendidos
por funcionário das vendas efetuadas entre os dias 01/03/2015 e 01/07/2015, em
5.4 Resultados obtidos
76
que contenha, entre a descrição do produto, a expressão "de", e exibir somente os
resultados cuja somatória da quantidade seja maior ou igual a 3.
• Relações utilizadas: Vendas, ItensVenda, Funcionarios e Produto.
• Bancos de dados utilizados: Cassandra, Postgresql e MSSQL Server.
• Recursos SQL: inner join para junção, between para intervalo de datas, sum para
somatória de campos númericos, like para textos aproximados, group by para
agrupamento, order by para ordenação e having para filtrar a partir da cláusula
group by.
O comando SQL correspondente à Consulta 10 é apresentado na Figura 5.32 e o
resultado da consulta é apresentado na Figura 5.33.
Figura 5.32: Exemplo - Consulta 10
Figura 5.33: Resultado da Consulta 10
Consulta 11: exemplo de consulta que acessa dois bancos de dados relacionais
e dois bancos de dados NOSQL.
5.4 Resultados obtidos
77
• Objetivo da consulta: apresentar as vendas efetuadas entre os dias 15/05/2015 e
01/07/2015 de todos os clientes cujo o nome inicie com a letra J.
• Relações utilizadas: Vendas, ItensVenda, Cliente, Funcionarios e Produto.
• Bancos de dados utilizados: Cassandra, MongoDB, Postgresql e MSSQL Server.
• Recursos SQL: inner join, left join, right join para junção, operadores >= e <= para
especificar intervalo de datas, like para textos aproximados, as para criação de alias,
order by para ordenação.
O comando SQL correspondente à Consulta 11 é apresentado na Figura 5.34 e o
resultado da consulta é apresentado na Figura 5.35.
Figura 5.34: Exemplo - Consulta 11
Figura 5.35: Resultado da Consulta 11
Após a execução dos experimentos, alguns aspectos referentes as consultas de
entrada e os resultados produzidos devem ser considerados:
5.5 Considerações Finais
78
• Algumas consultas foram escritas precedendo o atributo com o nome da relação
ao qual pertence. Essa restrição é válida se na consulta de entrada ou no mesmo
domínio houver dois ou mais atributos com o mesmo nome. Desta forma, é
necessário informar a relação que mantém o atributo para que a consulta seja
composta pelo atributo correto.
• Em consultas contendo intervalo entre datas, foram utilizados os operadores
between e >= e <=. Essa situação foi apresentada apenas para mostrar que existem as duas maneiras de especificar um intervalo de datas, mesmo se o atributo
estiver armazenado em um banco de dados NOSQL.
• Nos resultados de cada consulta, foram exibidos atributos que, inicialmente, não são
úteis para visualização, tais como: IdCliente, IdVenda, IdProduto e outros atributos
que indicam relacionamentos. Este fato ocorre pois, ao final de todos os processos,
a consulta de entrada é executada no depósito Resultados, e este depósito é criado
com base nas novas consultas SQL criadas para cada relação envolvida na consulta
de entrada e nos atributos de cada relação solicitados na consulta, como já foi
explicado anteriormente. Portanto, no depósito de Resultados devem conter todos
os atributos solicitados na consulta de entrada, inclusive os atributos que indicam
relacionamentos.
Os resultados obtidos mostram que o acesso aos bancos de dados relacionais
e NOSQL através de uma única consulta foi possível através do driver JDBC de cada
banco de dados. Ao receber a consulta no padrão SQL, o driver JDBC faz o mapeamento
dos elementos SQL para cada banco de dados, relacional ou NOSQL. Portanto, para a
viabilidade do método, é indispensável a utilização do driver JDBC de cada banco de
dados acessível pelo método.
A partir da utilização do protótipo e dos resultados obtidos, foi possível analisar
que a configuração dos metadados de conexão e armazenamento deve ser realizada por
pessoas que conhecem o domínio sobre o qual as consultas serão executadas. Isso se deve
ao fato de que, na abordagem adotada neste trabalho, os metadados são configurados
manualmente, sendo indispensável a interação de uma pessoa com o protótipo.
5.5
Considerações Finais
Neste capítulo foi apresentado e ilustrado o protótipo desenvolvido para aplicar
o método proposto. Foram discutidas todas as configurações realizadas para acessar
os bancos de dados envolvidos na consulta, bem como as configuração das relações e
atributos dos bancos de dados acessíveis pelo protótipo. A partir da implementação do
protótipo, foi possível validar o método proposto neste trabalho e verificar que é possível
5.5 Considerações Finais
79
realizar a integração de dados armazenados em bancos de dados relacionais e NOSQL,
e utilizar elementos SQL em consultas executadas em bancos de dados NOSQL. No
próximo capítulo serão discutidas as conclusões e trabalhos futuros.
CAPÍTULO 6
Conclusão
Este trabalho propõe um método de integração de dados armazenados em bancos
de dados de diferentes abordagens. O método permite o acesso a dados armazenados
em bancos de dados distribuídos e de diferentes modelos, para dar resposta a uma
única consulta escrita em SQL, que pode conter elementos SQL não reconhecidos por
determinadas abordagens de bancos de dados.
Convém destacar que bancos de dados NOSQL não oferecem, de forma nativa,
acesso aos dados que armazenam por meio de comandos SQL. O presente método, com
o propósito de padronizar a forma de acesso às fontes de dados disponíveis adotou a API
JDBC. Em consequência, qualquer que seja a fonte de dados, a existência de um driver
JDBC correspondente é obrigatória.
O método é capaz de analisar a consulta inicial, identificar os bancos de dados,
as relações e os atributos envolvidos. Após esse procedimento, a partir da consulta inicial,
são geradas consultas SQL específicas para cada banco de dados contendo informações
relevantes para a consulta. Os resultados obtidos pelas consultas específicas são armazenados temporariamente em um banco de dados relacional, o que torna possível submeter
a consulta inicial e obter o resultado final, composto por dados previamente recuperados
de vários bancos de dados.
Este trabalho foi inspirado em [45], no qual é proposto um método de integração
de dados entre bancos de dados relacionais e NOSQL. Entretanto, o método proposto
neste trabalho permite a utilização da linguagem de consulta SQL como meio padrão de
consulta dos dados. Como consequência, é permitida a utilização de elementos SQL, tais
como sum, count, join e outros elementos, mesmo que os dados estejam armazenados em
bancos de dados NOSQL.
As próximas seções apresentam as contribuições, os trabalhos futuros e os
trabalhos produzidos durante o desenvolvimento desta dissertação.
6.1 Contribuições
6.1
81
Contribuições
Nesta seção são apresentadas as principais contribuições com o desenvolvimento
deste trabalho.
• Permitir acessar fontes de dados de diferentes abordagens através de uma única
consulta SQL: os dados solicitados em uma consulta podem estar armazenados
em diferentes fontes de dados, porém, uma consulta SQL de entrada contendo as
relações e atributos desejados é o suficiente para retornar o resultado.
• Fornecer um mecanismo homogêneo de acesso aos bancos de dados: a API JDBC é
utilizada para fornecer uma interface de comunicação entre a aplicação e os bancos
de dados envolvidos na consulta.
• Permitir a construção de consultas SQL para cada banco de dados envolvidos
na consulta inicial: a partir da consulta SQL de entrada, o método é capaz de
identificar, através de metadados previamente configurados, as relações, atributos
e os bancos de dados em que os dados estão armazenados.
• Executar consultas SQL contendo elementos não reconhecidos pela abordagem
NOSQL: a utilização da linguagem de consulta SQL como meio de consulta aos
dados, permite executar consultas com sum, count, join e outros elementos SQL.
• Permitir integração de dados armazenados em bancos de dados relacionais e
NOSQL: os dados armazenados em bancos de dados relacionais e NOSQL são
consultados através de uma única consulta, e os resultados produzidos em cada
banco de dados são apresentados de forma unificada.
6.2
Trabalhos Futuros
Durante o desenvolvimento do trabalho foram identificados vários aspectos que
podem contribuir para o aprimoramento do método proposto. Dentre eles, estão:
• Permitir consultas não necessariamente no padrão SQL: para executar consultas
utilizando o método proposto, é necessário informar uma consulta no padrão SQL e
respeitar rigorosamente a sintaxe SQL. Uma alternativa seria disponibilizar outras
formas de se submeter uma consulta SQL, mesmo não sendo no padrão SQL.
• Permitir a integração de dados considerando outras fontes de dados: o método
proposto reconhece apenas os bancos de dados relacionais e NOSQL. A integração
de dados com outras fontes de dados poderiam ser implementadas, tais como:
arquivos texto, arquivos XML, emails e outras fontes de dados.
• Permitir a integração de dados entre bancos de dados relacionais e outras categorias de bancos de dados NOSQL: neste trabalho foram considerados apenas bancos
6.2 Trabalhos Futuros
82
de dados relacionais e as categorias NOSQL orientado a colunas e orientado a documentos. Entretanto, é importante realizar a integração entre outras categorias de
bancos de dados NOSQL, tais como: orientado a grafos, chave-valor, bancos de
dados XML e outros.
• Avaliar o desempenho do método de integração de dados em situações reais:
devido às características do trabalho aqui proposto, durante o seu desenvolvimento
não foi possível encontrar um ambiente real para executar os experimentos. Em
um ambiente real contendo bancos de dados relacionais e NOSQL, seria possível
avaliar melhor o método proposto.
• Permitir a execução de operações inserção, alteração e exclusão de dados: este
trabalho foi desenvolvido considerando apenas a operação de consulta. Permitir
outras operações SQL significa construir um método completo que contemple todas
as operações.
• Permitir utilizar outros elementos SQL não contemplados neste trabalho: o método
proposto neste trabalho permite realizar consultas contendo elementos SQL não
reconhecidos pelos bancos de dados NOSQL, como: sum, count, min, max, avg,
join, in, and, or, like, between. No entanto, não são todos os elementos SQL que
são aceitos neste trabalho. Permitir executar consultas contendo, por exemplo:
subconsultas, inserção de dados através de consultas e até mesmo contemplar
as especificidades de cada banco de dados é importante para o método executar
quaisquer elementos da linguagem SQL.
APÊNDICE A
Dados para executar os experimentos
As tabelas a seguir apresentam os dados utilizados para realizar os experimentos.
Coleção de documentos Clientes
IdClienteC
Nome
1
Flavio Vilela
2
Cidade
Telefone
Rua Voluntarios
da Patria, 353
Jatai
6436311873
Jose Caetano de Assis
Rua Miguel de
Assis, 1153
Jatai
6436325487
3
Joao Caetano de Assis
Rua Riachuello,
451
Goiania
6436254874
4
Pedro Jose dos Santos
Rua Pires do Rio,
1251
Goiania
6236124874
Jatai
6436361254
Goiania
6432546321
5
Endereco
Joaquim Caetano de Assis Avenida Voluntarios da Patria, 121
6
Junior dos Santos
Avenida
222
Goias,
7
Larissa de Assis Vilela
Avenida Presidente
Vargas,
562
8
Lorena de Assis Vilela
Rua da saudade,
221
Acreuna 6436456321
Jatai
Tabela A.1: Dados armazenados na coleção de documentos Clientes
6436312102
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
84
Coleção de documentos CondPag
IdCondPag
DescricaoCP
1
Dinheiro
2
Cartao
3
Cheque
4
Promissoria
Tabela A.2: Dados armazenados na coleção de documentos CondPag
Coleção de documentos Fornecedor
IdFornecedor RazaoSocial
CNPJ
Endereco
Cidade
1
JR Distribuidora
123456-1
Rua X, 223
Jatai-GO
2
Vilela Implementos 456123-2
Agricolas
Rua Y, 2301
Jatai-GO
3
MKT Pecas e Aces- 854565-1
sorios
Rua Z, 32
Jatai-GO
4
Coringa das Rodas 201202-1 Rua K, 1200
LTDA
Jatai-GO
5
FAV Molas e Parafu- 784452-8
sos
Jatai-GO
6
Junior Auto Pecas e 552211-8 Rua A, 1256 Goiania-GO
Distribuidora LTDA
7
Comando
Agricolas
Pecas 200112-3
Rua C, 556
Goiania-GO
8
Reg Implementos e 885696-5
Pecas
Rua C, 452
Goiania-GO
9
Distribuidora Lopes 102325-6
LTDA
Rua C, 5655
Goiania-GO
10
Trovao Pecas e Im- 452123-9
plementos
Rua B, 6633
Goiania-GO
Rua W, 56
Tabela A.3: Dados armazenados na coleção de documentos Fornecedor
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
85
Família de colunas Vendas
IdVenda
IdCliente IdCondPag IdFuncionario DataVenda
1
1
1
1
2015-02-01
2
1
2
2
2015-02-02
3
2
2
3
2015-03-03
4
2
1
4
2015-03-15
5
3
1
5
2015-04-20
6
3
1
1
2015-04-22
7
4
2
2
2015-05-31
8
7
2
3
2015-05-06
9
5
2
4
2015-06-10
10
6
1
5
2015-06-19
11
1
1
1
2015-02-20
12
1
2
2
2015-02-22
13
2
2
3
2015-03-21
14
2
1
4
2015-03-20
15
7
3
5
2015-04-24
16
3
4
1
2015-04-30
17
4
3
2
2015-05-01
18
4
3
3
2015-05-01
19
5
2
4
2015-06-01
20
6
4
5
2015-06-01
21
6
4
1
2015-06-20
22
7
4
2
2015-07-05
23
6
1
3
2015-07-10
24
8
2
4
2015-07-02
25
6
3
5
2015-07-03
26
7
3
1
2015-08-02
27
6
2
2
2015-08-02
28
1
2
3
2015-08-03
29
2
4
4
2015-09-15
30
3
1
5
2015-09-20
Tabela A.4: Dados armazenados na família de colunas vendas
Família de colunas ItensVendas
IdVenda IdProduto
1
1
PrecoUnitario Quantidade SubTotal
10
2
20
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
86
1
2
20
4
80
1
3
30
2
60
1
4
35
2
70
1
5
50
2
100
1
6
5
2
10
2
2
35
2
70
2
1
10
2
20
2
3
5
2
10
3
3
5
2
10
3
4
7
2
14
3
1
5
2
10
4
1
100
3
300
4
2
200
5
1000
4
3
300
3
900
4
4
350
3
1050
4
5
500
2
1000
4
6
50
1
50
5
1
350
2
700
5
2
100
4
400
5
3
50
1
50
6
1
50
1
50
6
8
70
2
140
6
7
10
3
30
6
9
20
1
20
7
1
20
3
60
7
4
30
5
150
7
3
40
4
160
7
5
55
3
165
8
2
55
3
165
8
1
44
8
352
8
3
64
3
192
8
4
70
4
280
9
6
88
3
264
9
5
99
5
495
9
1
77
3
231
9
2
44
6
264
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
87
10
2
45
3
135
10
1
20
6
120
10
3
20
3
60
10
4
11
7
77
10
6
22
8
10
10
10
32
1
32
11
1
31
9
279
11
2
30
2
60
11
3
10
3
30
11
4
55
4
220
12
2
20
1
20
12
3
10
2
20
12
5
54
5
270
12
6
56
6
336
12
8
70
1
70
13
7
80
2
160
13
9
99
3
297
13
8
500
4
2000
13
4
501
8
4008
14
4
40
4
160
14
5
44
5
220
15
6
55
2
110
15
5
44
1
44
15
2
11
1
11
15
1
24
1
24
15
7
26
2
52
15
9
27
3
81
15
10
28
2
56
15
8
45
2
90
16
1
65
3
195
16
2
10
4
40
16
3
15
5
75
16
4
25
3
75
16
5
35
7
245
17
1
70
3
210
17
5
40
7
280
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
88
17
6
15
3
45
17
7
16
3
48
17
8
30
3
30
18
1
10
8
80
18
2
25
9
225
18
3
10
3
30
18
4
30
1
30
19
2
24
3
72
19
5
26
2
52
20
4
35
3
105
20
6
40
2
80
20
7
60
3
180
20
8
70
1
70
21
2
80
3
240
21
3
90
2
180
21
5
77
3
231
21
4
10
2
20
21
8
40
3
120
22
7
60
7
420
22
8
20
2
20
22
9
14
2
28
22
10
10
2
20
23
2
30
1
30
23
3
10
1
10
24
4
5
2
10
24
5
7
2
14
24
6
95
2
190
24
7
10
2
20
25
1
41
3
123
25
2
12
1
12
25
8
35
3
105
26
8
63
3
189
26
9
32
2
64
27
10
41
2
82
27
8
25
1
25
27
7
26
3
78
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
89
27
4
70
2
140
28
1
51
2
102
28
2
13
1
13
28
3
10
3
13
28
4
70
1
70
29
8
5
2
10
29
7
6
2
12
30
9
50
2
100
30
7
70
4
280
30
8
20
3
60
30
4
80
5
400
30
5
50
3
150
Tabela A.5: Dados armazenados na família de colunas ItensVendas
Relação Produto
IdProduto
DescricaoProduto
Codigo
1
Prato descartável
123
2
4
2
Colher de metal
3322
1.5
3
3
Prato de video
929281
10
2
4
Relogio Casio
3939
10
2
5
Livro de Android
883
100
3
6
Livro de java
788854
150
5
7
Bolsa Company
992222
1500
2
550
8
8
Celular Black Barry 28282811
PrecoUnitario Estoque
9
Celular Nexus 5
22828919
600
9
10
Mouse Lazer
399322
25
2
Tabela A.6: Dados armazenados na relação Produto
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
90
Relação Funcionarios
IdFuncionario NomeFuncionario
Endereco
Comissao
Cidade
Salario
1
José Pereira
Rua A, 12
2
Goiania
1000
2
João da Silva
Rua B, 13
2
Goiania
2000
3
Joaquim de Moura
Rua C, 14
3
Goiania
900
4
Felipe Alves
Rua D, 15
3
Jataí
1000
5
Flávio Vilela
Rua E, 16
2
Jataí
3000
Tabela A.7: Dados armazenados na relação Funcionarios
Relação EntradaNFe
IdEntrada IdFornecedor IdFuncionario DataEntrada
ValorTotal
1
1
1
2014-06-25
89
2
2
1
2014-06-25
344
3
4
2
2014-06-20
107
4
2
3
2014-02-01
96
5
3
3
2015-02-15
195
6
2
2
2015-03-03
46
7
1
4
2015-02-20
1579
8
3
4
2015-03-15
148
9
4
5
2015-04-04
407
10
3
4
2015-01-01
1059
11
6
2
2015-04-01
144
12
7
3
2014-09-15
149
13
8
1
2014-01-01
196
14
7
3
2014-12-01
110
15
8
2
2014-11-19
199
16
9
4
2014-09-20
191
17
10
2
2014-09-21
211
18
9
5
2014-11-20
21
19
7
1
2015-12-19
234
20
10
3
2015-11-20
211
Tabela A.8: Dados armazenados na relação EntradaNFe
Relação ItensEntrada
IdEntrada IdProduto ValorCompra Quantidade SubTotal
1
1
10
2
20
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
91
1
2
20
2
40
1
3
5
3
15
1
4
7
2
14
2
5
50
2
100
2
6
60
1
60
2
7
30
3
90
2
8
20
3
60
2
9
3
3
9
2
10
5
5
25
3
1
10
3
30
3
2
20
3
60
3
3
5
2
10
3
4
7
1
7
4
5
6
1
6
4
6
60
1
60
4
7
15
2
30
5
8
5
2
10
5
9
3
5
15
5
10
10
5
50
5
1
10
5
50
5
2
20
3
60
5
3
5
2
10
6
4
7
3
21
6
5
5
5
25
7
6
60
10
600
7
7
30
30
900
7
8
5
10
50
7
9
3
3
9
7
10
10
2
20
8
1
10
3
30
8
2
20
3
60
8
3
5
5
25
8
4
7
4
28
8
5
5
1
5
9
6
60
5
300
9
7
30
2
60
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
92
9
8
5
5
25
9
9
3
4
12
9
10
10
1
10
10
1
10
2
20
10
2
20
30
600
10
3
5
5
25
10
4
7
7
49
10
5
5
1
5
10
6
60
6
360
11
7
30
2
60
11
8
5
3
15
11
9
3
3
9
11
10
10
3
30
11
1
10
63
30
12
2
20
60
120
12
3
5
1
5
12
4
7
2
14
12
5
5
2
10
13
6
60
2
120
13
7
30
2
60
13
8
5
2
10
13
9
3
2
6
14
10
10
2
20
14
1
10
2
20
14
2
20
3
60
14
3
5
2
10
15
4
7
2
14
15
5
5
1
5
15
6
60
3
180
16
7
30
2
60
16
8
5
2
10
16
9
3
2
6
16
10
10
2
20
16
1
10
3
30
16
2
20
2
40
16
3
5
5
25
APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS
93
17
4
7
3
21
17
5
5
2
10
17
6
60
2
120
17
7
30
2
60
18
8
5
1
5
18
9
3
2
6
18
10
10
1
10
19
1
10
5
50
19
2
20
8
160
19
3
5
2
10
19
4
7
2
14
20
5
5
5
25
20
6
60
2
120
20
7
30
1
30
20
8
5
2
10
20
9
3
2
6
20
10
10
2
20
Tabela A.9: Dados armazenados na relação ItensEntrada
Referências Bibliográficas
[1] A BRAMOVA , V.; B ERNARDINO, J.
Nosql databases - mongodb vs cassandra.
Proceedings of the International C* Conference on Computer Science and Software
Engineering (C3S2E ’13), 1:14–22, 2013.
[2] B ARBULESCU, M.; G RIGORIU, R.-O.; H ALCU, I.; N ECULOIU, G.; S ANDULESCU, V IR GINIA ,
C.; M ARINESCU, M.; M ARINESCU, V.
Integrating of structured, semi-
structured and unstructured data in natural and build environmental engineering. Roedunet International Conference (RoEduNet), 2013 11th, 1:1–4, 2013.
[3] B LUMBERG , R.; ATRE , S. The Problem with Unstructured Data. DM Review, 2003.
[4] C ALIL , A.; DOS S ANTOS , M ELLO, R. Simplesql: A relational layer for simpledb.
ADBIS’12 Proceedings of the 16th East European conference on Advances in Databases and Information Systems, 1:99–110, 2012.
[5] C ASSANDRA .
Cassandra
jdbc
driver,
12
2014.
https://code.google.com/a/apache-extras.org/p/cassandra-jdbc/.
Disponível
Acesso
em:
em:
5
dez. 2014.
Cassandra query language (cql).
[6] C ASSANDRA , A.
Disponível em:
https://cassandra.apache.org/doc/cql3/CQL.html. Acesso em: 4 set. 2014.
[7] C ASSANDRA , A.
Apache cassandra documentation, 2015.
Disponível em:
http://docs.datastax.com/en/cassandra/2.0/cassandra/gettingStartedCassandraIntro.html.
Acesso em: 15 dez. 2014.
[8] C ATTELL , R. Scalable sql and nosql data stores. ACM SIGMOD Record, 39(4):12–
27, Dezembro 2010.
[9] C HUNG , W.-C.; L IN , H.-P.; C HEN , S.-C.; J IANG , M.-F.; C HUNG , Y.-C. Jackhare:
a framework for sql to nosql translation using mapreduce. Automated Software
Engineering, 21:489–508, 2013.
[10] DOS S ANTOS , F ERREIRA , G.; C ALIL , A.; DOS S ANTOS , M ELLO, R. On providing
ddl support for a relational layer over a document nosql database. IIWAS ’13
REFERÊNCIAS BIBLIOGRÁFICAS
95
Proceedings of International Conference on Information Integration and Web-based
Applications & Services, 1:1–8, 2013.
[11] D UGGAN , J.; E LMORE , A ARON , J.; S TONEBRAKER , M.; B ALAZINSKA , M.; H OWE , B.
The bigdawg polystore system. SIGMOD Record, 44:11–16, 2015.
[12] G EETHA , S.; M ALA , D. G. S. A.
unstructured data.
Effectual extraction of data relations from
Third International Conference on Sustainable Energy and
Intelligent System, 1:1–4, 2012.
[13] H AN , J.; E, H.; L E , G.; D U, J. Survey on nosql database. In Proceedings of 6th
International Conference on Pervasive Computing and Applications (ICPCA 2011),
1:363–366, Outubro 2011.
[14] H ECHT, R.; J ABLONSKI , S. Nosql evaluation - a use case oriented survey. 2011
International Conference on Cloud and Service Computing, 1:336–341, Dezembro
2011.
[15] J ATANA , N.; P URI , S.; A HUJA , M.; K ATHURIA , I.; G OSAIN , D.
A survey and
comparison of relational and non-relational database. International Journal of
Engineering Research & Technology (IJERT), 1(6):1–5, 2012.
[16] KOZLOVA , I.; R ITTER , N.; R EIMER , O. Towards integrated query processing for
object-relational and xml data sources. 10th International Database Engineering
and Applications Symposium, 1:1, 2006.
[17] L AWRENCE , R. Integration and virtualization of relational sql and nosql systems
including mysql and mongodb. 2014 International Conference on Computational
Science and Computational Intelligence (CSCI), 1:285 – 290, 2014.
[18] L EAVITT, N. Will nosql databases live up to their promise? In IEEE Computer,
43(2):12–14, 2010.
[19] L I , Y.; M ANOHARAN , S. A performance comparison of sql and nosql databases.
Communications, Computers and Signal Processing (PACRIM), 2013 IEEE Pacific
Rim Conference on, 23:15–19, 2013.
[20] M C G REAL , R. Learning objects and metadata understanding the field. International Workshop on Technology for Education (T4E), 1:49 – 53, 2009.
[21] M OHAMED, M OHAMED, A.; A LTRAFI , O BAY, G.; I SMAIL , M OHAMMED, O. Relational
vs. nosql databases: A survey. International Journal of Computer and Information
Technology (ISSN: 2279 – 0764), 3(3):598–601, 2014.
REFERÊNCIAS BIBLIOGRÁFICAS
Introduction
[22] M ONGO DB.
96
to
mongodb,
2
2015.
Disponível
em:
http://docs.mongodb.org/manual/reference/sql-comparison/. Acesso em: 5 fev.
2015.
[23] M ONGO DB, U.
Jdbc driver for mongodb, 2014 12.
Disponível em:
http://www.unityjdbc.com/mongojdbc/mongojdbc.php. Acesso em: 15 dez. 2014.
[24] M ONIRUZZAMAN , A. B. M.; H OSSAIN , S YED, A. Nosql database - new era of databases for big data analytics - classification, characteristics and comparison.
International Journal of Database Theory and Application, 6:1–14, 2013.
[25] N ANCE , C.; L OSSER , T.; I YPE , R.; H ARMON , G. Nosql vs rdbms - why there is
room for both. Proceedings of the Southern Association for Information Systems
Conference, Savannah, GA, USA., 27:111–116, 2013.
[26] NOSQL.
List of nosql databases, 1 2015.
Disponível em: http://nosql-
database.org. Acesso em: 20 jan. 2014.
[27] N YATI , S. S. Performance evaluation of unstructured nosql data over distributed
framework. Advances in Computing, Communications and Informatics (ICACCI),
2013 International Conference on, 1:1623 – 1627, 2013.
[28] PARKER , Z.; P OE , S.; V RBSKY, S. V. Comparing nosql mongodb to an sql db.
Proceedings of the 51st ACM Southeast Conference, 5:1–6, 2013.
[29] P OKORNY, J. Nosql databases: a step to database scalability in web environment. Proceedings of the 13th International Conference on Information Integration
and Web-based Applications and Services, iiWAS’11, 9:278–283, 2011.
[30] PRESS, N. Understanding Metadata. National Information Standards Organization, 2004.
[31] R AMAKRISHNAN , R.; G EHRKE , J. Database Management System. McGraw-Hili,
2003.
[32] R OUT, T.; G ARANAYAK , M.; S ENAPATI , M ANAS , R.; K AMILLA , S USHANTA , K. Big data
and its applications: A review. International Conference on Electrical, Electronics,
Signals, Communication and Optimization (EESCO) - 2015, 1:1–5, 2015.
[33] S CHRAM , A. Mysql to nosql data modeling challenges in supporting scalability.
Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity, 1:191–202, 2012.
REFERÊNCIAS BIBLIOGRÁFICAS
97
[34] S ILVA , J OÃO, C.; KOWATA , E. T.; V INCENZI , A. M. R. Extracting and exposing
relational database metadata on the web. Proceedings of IADIS International
Conference WWW/Internet. Madrid, Spain, 1:35–42, 2012.
[35] S MULLEN , C LINTON , W.; TARAPORE , S HAHRUKH , R.; G URUMURTHI , S. A benchmark suite for unstructured data processing. Fourth International Workshop on
Storage Network Architecture and Parallel I/Os, 1:79 – 83, 2008.
[36] S OMMERVILLE , I. Engenharia de Software. Pearson, 2011.
[37] S TONEBRAKER , M.; M ADDEN , S.; A BADI , DANIEL , J.; H ARIZOPOULOS , S.; H ACHEM ,
N.; H ELLAND, P. The end of an architectural era. VLDB ’07 Proceedings of the
33rd international conference on Very large data bases, 1:1150–1160, 2007.
[38] S U, J.; FAN , R.; L I , X. Research and design of heterogeneous data integration
middleware based on xml. Intelligent Computing and Intelligent Systems (ICIS),
2010 IEEE International Conference on, 2:850 – 854, 2010.
[39] TAURO, C LARENCE , J. M.; A RAVINDH , S.; A, B. S. Comparative study of the new
generation, agile, scalable, high performance nosql databases. International
Journal of Computer Applications (0975 888), 48:1–4, Junho 2012.
[40] T UDORICA , B OGDAN , G.; B UCUR , C. A comparison between several nosql databases with comments and notes. Roedunet International Conference (RoEduNet),
2011 10th, 5:1 – 5, 2011.
[41] VANGIPURAM , R. K.; S REEKANTH , V.; R ANGASWAMY, B. Implementation of web-etl
transformation with pre-configured multi-source system connection and transformation mapping statistics report. 3rd International Conference on Advanced
Computer Theory and Engineering(ICACTE), 2:317–322, 2010.
[42] WANG , G.; TANG , J. The nosql principles and basic application of cassandra
model. Computer Science & Service System (CSSS), 2012 International Conference
on, 1:1332 – 1335, 2012.
[43] W EI - PING , Z.; M ING - XIN , L.; H UAN , C. Using mongodb to implement textbook
management system instead of mysql. Communication Software and Networks
(ICCSN), 2011 IEEE 3rd International Conference on, 11:303 – 305, 2011.
[44] W ILEY, J. Practical Database Programming with Java Chapter 3 - JDBC API and
JDBC Drivers. Ying Bai, 1 edition, 2011.
REFERÊNCIAS BIBLIOGRÁFICAS
98
[45] Z HANG , H.; WANG , Y.; H AN , J.
Middleware design for integrating relational
database and nosql based on data dictionary. 2011 International Conference on
Transportation, Mechanical, and Electrical Engineering (TMEE), 1:1469–1472, 2011.
[46] Z HANG , H.; Z HANG , L.- Y. Jdbc-based middleware applications in instant message systems. 2nd International Conference on Systems and Informatics (ICSAI
2014), 1:1044 – 1049, 2014.