um método de integração de dados armazenados em bancos de …¡vio... · 4.6 estrutura de um...

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

FLÁVIO DE ASSIS VILELA

Um método de integração de dadosarmazenados em bancos de dados

relacionais e NOSQL

Goiânia2015



relacionais e NOSQL

Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emComputaçã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ânia2015



relacionais e NOSQL

Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara obtenção do título de Mestre em Computação, aprovada em07 de Setembro de 2015, pela Banca Examinadora constituída pelosprofessores:

Prof. Dr. João Carlos da SilvaInstituto de Informática – UFG

Presidente da Banca

Prof. Dr. Fábio Nogueira de LucenaInstituto de Informática – UFG

Prof. Dr. Leonardo Andrade RibeiroUniversidade Federal de Goiás – UFG

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho 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 - Cam-pus Jataí. Possui o título de Especialista em Desenvolvimento de Softwarepela 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 apoi-aram 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, meaceitou como seu orientando, e, desde então, foi a pessoa que mais contribuiu na minhaformação acadêmica, intelectual e pessoal. Agradeço pelos conhecimentos em Banco deDados com ele adquiridos, pela disponibilidade, pela paciência e pela confiança em mimdepositado.

Agradeço ao professor Dr. Fábio Nogueira de Lucena que desempenhou umpapel importante para a conclusão deste trabalho. Em todo o momento, não mediuesforços para me atender, sempre com novas idéias para melhorar o trabalho e meajudando imensamente em dúvidas referentes à implementação. Agradeço ainda pelapaciê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 daescrita do texto. Aos colegas de disciplinas que fiz durante o mestrado, especialmente aWalquiria e ao Cleon, pessoas que estiveram ao meu lado durante todo este longo percursoe, 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 fizera leitura deste trabalho. Agradeço a você, minha irmã Larissa, por sempre ter sido umapessoa 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 pramorar 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 embancos de dados relacionais e NOSQL. Goiânia, 2015. 98p. Dissertação deMestrado. Instituto de Informática, Universidade Federal de Goiás.

O aumento da quantidade e variedade de dados disponíveis na Web contribuiu com o sur-gimento da abordagem NOSQL, visando atender novas demandas, como disponibilidade,flexibilidade de esquema e escalabilidade. Paralelamente, bancos de dados relacionais sãolargamente utilizados para armazenamento e manipulação de dados estruturados, ofere-cendo estabilidade e integridade de dados, que são acessados através de uma linguagempadrão, como SQL. Este trabalho apresenta um método de integração de dados armaze-nados em fontes heterogêneas, no qual uma consulta de entrada em SQL produz uma res-posta 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 deInformática, Universidade Federal de Goiás.

The increase in quantity and variety of data available on the Web contributed to theemergence of NOSQL approach, aiming at new demands, such as availability, schemaflexibility and scalability. At the same time, relational databases are widely used forstoring and manipulating structured data, providing stability and integrity of data, whichis accessed through a standard language such as SQL. This work presents a method forintegrating data stored in heterogeneous sources, in which an input query in standardSQL produces a unified answer, based in the partial answers of relational and NOSQLdatabases.

Keywords

Data integration, relational database, NoSQL Database.

Sumário

Lista de Figuras 10

Lista de Tabelas 12

1 Introdução 11.1 Contextualização 11.2 Objetivos 31.3 Principais necessidades 41.4 Desafios encontrados 41.5 Restrições do método proposto 51.6 Organização do texto 6

2 Trabalhos Relacionados 72.1 Integração de dados entre bancos de dados relacionais e NOSQL 72.2 Integração de dados entre bancos de dados relacionais e outras fontes de dados 9

3 Fundamentação teórica 183.1 Modelo relacional 183.2 Abordagem NOSQL 20

3.2.1 Modelo de dados 213.2.2 Categorias de bancos de dados NOSQL 213.2.3 Outras características da abordagem NOSQL 28

3.3 Dados estruturados e não estruturados 303.4 Metadados 323.5 Arquitetura JDBC 33

3.5.1 Driver JDBC para Cassandra 353.5.2 Driver JDBC para MongoDB 36

4 Um método para integração de dados armazenados em bancos de dadosrelacionais e NOSQL 374.1 Modelo da solução proposta 374.2 Estrutura do método 38

4.2.1 Consulta SQL Inicial 384.2.2 Depósitos de dados 39

Elementos SQL 40Metadados 41Fontes de Dados 44Resultados 44

4.2.3 Analisar Consulta SQL 44

4.2.4 Construir Comandos SQL 464.2.5 Controlar Execução de Consultas SQL 484.2.6 Gerenciar Resultados 494.2.7 Exemplo passo a passo 50

5 Um protótipo para avaliar o método de integração de dados 535.1 Desafios encontrados durante o desenvolvimento 535.2 Requisitos do protótipo 545.3 Descrição do protótipo 55

5.3.1 Tecnologias utilizadas 555.3.2 Funcionalidades do protótipo 55

5.4 Resultados obtidos 585.4.1 Ambiente dos experimentos 595.4.2 Exemplos de consultas 66

Consultas envolvendo apenas bancos de dados relacionais 67Consultas envolvendo apenas bancos de dados NOSQL 68Consultas envolvendo bancos de dados relacionais e bancos de dados NOSQL 74

5.5 Considerações Finais 78

6 Conclusão 806.1 Contribuições 816.2 Trabalhos Futuros 81

A Dados para executar os experimentos 83

Referências Bibliográficas 94

Lista de Figuras

2.1 Middleware de integração de dados criado em [45] 82.2 Estrutura do método criado em [4]. 122.3 Estrutura do método desenvolvido em [10]. 13

3.1 Tipos de dados gerados nos últimos anos [39]. 193.2 Estrutura do banco de dados chave-valor 223.3 Estrutura do banco de dados MongoDB [43] 223.4 Exemplo da estrutura de armazenamento do MongoDB 233.5 Comparação da sintaxe de criação de uma relação em banco de dados

relacional e MongoDB [22] 243.6 Comparação da sintaxe de inserção de dados em banco de dados relaci-

onal e MongoDB [22] 243.7 Comparação da sintaxe de consulta em banco de dados relacional e

MongoDB [22] 253.8 Estrutura de armazenamento do banco de dados Cassandra 263.9 Exemplo da sintaxe de criação de relações CQL [7] 273.10 Teorema CAP [42] 283.11 Exemplo de dados não estruturados 313.12 Tipos de drivers JDBC [46] 333.13 Exemplo da arquitetura JDBC [44] 35

4.1 Fluxo de dados do método proposto 394.2 Exemplo de consulta 394.3 Relações do depósito Elementos SQL 404.4 Outras relações do depósito Elementos SQL 414.5 Representação das relações que compõe os metadados 424.6 Estrutura de um banco de dados orientado a colunas mapeada para o

modelo relacional 434.7 Estrutura de um banco de dados orientado a documentos mapeada para

o modelo relacional 444.8 Exemplo de consulta SQL de entrada redefinida 454.9 Elementos SQL após a análise da consulta SQL 464.10 Consultas construídas pelo método. 484.11 Consulta inicial executada no depósito Resultados 50

5.1 Tela inicial do protótipo 555.2 Tela de cadastro metadados de conexão 565.3 Tela de cadastro de relações 575.4 Tela de cadastro de atributos 57

5.5 Tela de cadastro de domínios 585.6 Famílias de colunas criadas no banco de dados Cassandra. 605.7 Coleção de documentos Clientes criada no banco de dados MongoDB. 615.8 Coleção de documentos Fornecedor criada no banco de dados MongoDB. 615.9 Coleção de documentos CondPag criada no banco de dados MongoDB. 625.10 Relações criadas no banco de dados MSSQL Server. 635.11 Relação Funcionarios criada no banco de dados Postgresql. 645.12 Relações utilizadas no experimento 645.13 Ambiente dos experimentos 665.14 Exemplo - Consulta 1 675.15 Resultado da Consulta 1 675.16 Exemplo - Consulta 2 685.17 Resultado da Consulta 2 685.18 Exemplo - Consulta 3 695.19 Resultado da Consulta 3 695.20 Exemplo - Consulta 4 705.21 Resultado da Consulta 4 705.22 Exemplo - Consulta 5 715.23 Resultado da Consulta 5 715.24 Exemplo - Consulta 6 725.25 Resultado da Consulta 6 725.26 Exemplo - Consulta 7 735.27 Resultado da Consulta 7 735.28 Exemplo - Consulta 8 745.29 Resultado da Consulta 8 745.30 Exemplo - Consulta 9 755.31 Resultado da Consulta 9 755.32 Exemplo - Consulta 10 765.33 Resultado da Consulta 10 765.34 Exemplo - Consulta 11 775.35 Resultado da Consulta 11 77

Lista de Tabelas

2.1 Mapeamento da estrutura de um banco de dados relacional para o bancode dados SimpleDB [4]. 11

2.2 Características dos trabalhos relacionados 16

3.1 Comparação dos termos utilizados em bancos de dados relacionais eMongoDB [22] 23

3.2 Exemplos de consultas utilizando o CQL [7] 273.3 Comparação do tempo de inserção entre bancos de dados NOSQL e

relacional [19] 293.4 Exemplo de dados estruturados 313.5 Exemplo de metadados 32

4.1 Relações, atributos e predicados da relação Vendas. 504.2 Relações, atributos e predicados da relação Cliente. 514.3 Consultas SQL construídas para cada relação. 514.4 Relação Cliente criada no depósito Resultados. 514.5 Relação Vendas criada no depósito Resultados. 514.6 Resultado da consulta inicial executada no depósito Resultados. 52

5.1 Tabela de requisitos funcionais do protótipo 545.2 Tabela de requisitos não funcionais do protótipo 545.3 Configuração dos metadados de conexão no depósito Metadados 595.4 Conjunto de relações, coleções de documentos e famílias de colunas para

os experimentos. 60

A.1 Dados armazenados na coleção de documentos Clientes 83A.2 Dados armazenados na coleção de documentos CondPag 84A.3 Dados armazenados na coleção de documentos Fornecedor 84A.4 Dados armazenados na família de colunas vendas 85A.5 Dados armazenados na família de colunas ItensVendas 89A.6 Dados armazenados na relação Produto 89A.7 Dados armazenados na relação Funcionarios 90A.8 Dados armazenados na relação EntradaNFe 90A.9 Dados armazenados na relação ItensEntrada 93

CAPÍTULO 1Introdução

Este capítulo contextualiza o tema deste trabalho, a motivação, os objetivos edesafios encontrados. A seção 1.1 apresenta a contextualização. A seção 1.2 discute osobjetivos do trabalho. A seção 1.3 apresenta as principais necessidades identificadasdurante 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 apresentaas restrições para o método proposto. E por fim, a seção 1.7 apresenta a organização dotexto.

1.1 Contextualização

Os mecanismos de busca utilizados na Web (World Wide Web) tornaram-se umaimportante 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 pesquisabibliográfica para uma tese de doutorado. Um usuário pode obter resultados de consultasem diversos formatos, tais como tabelas, texto, páginas da Web, fotos e outros. Rout etal. [32] comentam sobre a quantidade de dados disponíveis na Web. De acordo com aspesquisas, a quantidade de dados estão na esfera de petabytes ou exabytes, que consisteem trilhões de registros de milhões de usuários. Todos estes dados são originados depá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 dedados definido e permitindo relacionamentos [28]. Por outro lado, também podem estar naforma 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 domodelo e da estrutura de armazenamento [12].

Durante anos, os bancos de dados relacionais foram utilizados como solução noarmazenamento de dados em diferentes cenários [17], em que uma das característicasprincipais é o uso da linguagem SQL para interagir com os banco de dados. Hecht eJablonski [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 manipuladospelas aplicações. Stonebraker et al. [37] argumentam que, inicialmente, os bancos dedados relacionais foram arquitetados com as características de hardware diferentes àsatuais, 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 dadoscomerciais.

A abordagem NOSQL surgiu com a proposta de oferecer recursos diferentes noarmazenamento de dados, baseando-se nas características encontradas em ambientes Web

[45], no qual se encontra uma grande massa de dados, podendo apresentar diferentes for-matos e serem acessados por vários usuários simultaneamente. Algumas características daabordagem NOSQL são: esquema flexível, alta disponibilidade e escalabilidade horizon-tal [14], [13], [25]. Existem, no entanto, recursos importantes que não estão disponíveisem bancos de dados NOSQL, como a linguagem de consulta SQL. Em vez disso, cadabanco 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 sendodados estruturados, não são, obrigatoriamente, armazenados em bancos de dados relaci-onais. A utilização de bancos de dados dessa abordagem está associada com o ambienteem que será implantada a aplicação, se haverá uma grande massa de dados sendo aces-sada simultaneamente, se haverá necessidade de executar consultas complexas com osbancos de dados, entre outras características. Entretanto, os dados podem ser do tipo nãoestruturado, e mesmo assim, não há relação em dizer que, obrigatoriamente, serão arma-zenados em bancos de dados NOSQL [28]. É possível armazenar dados estruturados embancos de dados NOSQL, no entanto, os bancos de dados dessa abordagem armazenamos 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 edurabilidade), 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 diversasfontes de dados [38], especificamente em bancos de dados relacionais ou bancos dedados NOSQL. Zhang et al. [45] apontam um exemplo em que uma aplicação consomeinformações de bases relacionais e NOSQL. Parte dos dados pode conter uma estruturadefinida, sobre os quais pode ser necessário realizar consultas com maior complexidadee 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 grandemassa 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, disponibilidadeda 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 umaconsulta, requisitando dados distribuídos em bancos de dados relacionais e NOSQL,e ainda, os bancos de dados podem estar distribuídos geograficamente entre váriasorganizações ou até mesmo em várias cidades [41].

Neste contexto, este trabalho apresenta um método capaz de consultar dadosarmazenados em bancos de dados relacionais e NOSQL, através de uma única consultaescrita no padrão da linguagem de consulta SQL, e apresentar o resultado de formaunificada. Em busca de criar um mecanismo único de acesso aos dados, considerando queos bancos de dados NOSQL não apresentam um padrão de linguagem de consulta, e paraviabilizar o uso da linguagem SQL como padrão de consulta, todos os bancos de dadosdisponíveis são descritos por um conjunto previamente estabelecido de metadados, e, paratodos os bancos de dados, deve ser disponível um driver JDBC. Os bancos de dadosNOSQL são representados na forma de relações e atributos, à semelhança da abordagemrelacional.

De acordo com [26], atualmente estão disponíveis aproximadamente 150 bancosde dados NOSQL, que compartilham algumas características semelhantes, porém ofe-recem 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 debancos de dados NOSQL das categorias orientada a colunas e documentos. A categoriaorientada a colunas se deve ao fato de sua estrutura de armazenamento ser comparada abancos de dados relacionais, armazenando os dados em uma estrutura composta de linhase colunas. A categoria orientada a documentos se justifica por armazenar os dados emuma estrutura diferente à orientada a colunas e relacionais, o que torna possível avaliar ométodo utilizando outras estruturas de armazenamento NOSQL.

1.2 Objetivos

Considerando um ambiente contendo dados armazenados em bancos de dadosrelacionais e NOSQL, o primeiro objetivo deste trabalho é apresentar um método capazde permitir que vários bancos de dados de diferentes abordagens sejam acessados a partirde uma única consulta escrita no padrão SQL e os resultados parciais obtidos em cadabanco de dados sejam mesclados e apresentados de forma unificada.

O segundo objetivo da pesquisa é a utilização dos recursos disponíveis em bancosde 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 desafioa integração dessas duas abordagens na mesma aplicação.

O terceiro objetivo está associado ao estudo de uma nova abordagem de bancode dados. A abordagem NOSQL, em comparação à abordagem relacional, é ainda poucaestudada e fundamentada. Com a pesquisa direcionada para esta abordagem, é possívelcontribuir com os estudos sobre NOSQL, podendo, ainda, identificar técnicas empregadaspara resolução de outros problemas referentes à integração de dados, além de suprir asnecessidades encontradas durante a pesquisa.

Os objetivos específicos do trabalho a fim de alcançar os objetivos gerais são:

• 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.

1.3 Principais necessidades

Zhang et al. [45] propôs um método com o qual é possível realizar a integraçãode dados entre bancos de dados relacionais e NOSQL (essa integração é discutida noCapítulo 2). Entretanto, algumas necessidades não abordadas naquele trabalho foramencontradas, que são:

• Permitir executar consultas contendo elementos de agregação e consequentementeo 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 foramencontrados:

• O trabalho empregado como principal referência para o presente trabalho não defineclaramente quais as técnicas desenvolvidas para alcançar o objetivo proposto.

• Não foram encontradas implementações que tratam do assunto de integração dedados 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 mecanismopadrão de comunicação. Cada banco de dados oferece maneiras diferentes de acessoaos 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 estuda-das nesta pesquisa, como a integração de dados armazenados em bancos de dados relaci-onais e NOSQL, utilização de junções, agregações e outros elementos, em consultas quenão são reconhecidas pela abordagem NOSQL, e apresenta, de forma detalhada, todos osprocessos executados. No entanto, não tem a pretensão de resolver todos os problemase/ou necessidades existentes referentes à integração de dados. As restrições do métodoproposto são apresentadas nessa seção.

• Normalmente, as consultas SQL são construídas contendo relações, atributos eoutros elementos disponíveis na linguagem de consulta SQL. Algumas palavras-chaves 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 quesã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 consultaSQL e, portanto, qualquer banco de dados que utilize esta linguagem de consultapoderá fazer uso desses recursos. No entanto, alguns bancos de dados implementamfunções próprias para obtenção de resultados diferentes. Por exemplo: a funçãotop, que é implementada pelo banco de dados MSSQL Server, tem a função delimitar a quantidade de registros que são retornados por uma consulta. No bancode dados Postgresql, essa mesma tarefa é executada pela função limit. No banco dedados Oracle, essa funcionalidade é representada pela função rownum. Portanto,as especificidades de cada banco de dados não são contempladas pelo métodoproposto.

• O método proposto não considera aspectos como: escalabilidade, desempenho,grande massa de dados sendo manipulados por vários usuários simultaneamentee outras características encontradas em ambientes que lidam com várias fontes dedados.

1.6 Organização do texto 6

1.6 Organização do texto

Após este capítulo que apresentou a contextualização, a motivação, as necessi-dades identificadas durante a pesquisa e os objetivos da pesquisa, o trabalho contém aindaoutros 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 deintegração de dados entre bancos de dados relacionais e bancos de dados NOSQL. O ca-pítulo 3 aborda os fundamentos técnicos que são necessários à compreensão do contextoem que a pesquisa foi realizada. O capítulo 4 apresenta o método proposto a fim suprir asnecessidades identificadas durante a pesquisa, além de apresentar a definição do escopodo projeto. O capítulo 5 apresenta a estrutura do protótipo que foi desenvolvido a fim de-monstrar a viabilidade do método proposto. Além disso, apresenta os resultados obtidosatravés da utilização do protótipo. E para finalizar, o capítulo 6 expõe as conclusões queforam obtidas no desenvolvimento do trabalho e trabalhos futuros.

CAPÍTULO 2Trabalhos Relacionados

O acesso a dados armazenados em bancos de dados relacionais e NOSQL, pormeio 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 aintegração de dados entre essas duas abordagens de bancos de dados, e a execução deconsultas em bancos de dados NOSQL utilizando a linguagem de consulta SQL, bemcomo a forma de acesso aos respectivos bancos de dados.

2.1 Integração de dados entre bancos de dados relacio-nais e NOSQL

O trabalho de Zhang et al. [45] apresenta um modelo de middleware que controlaa 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 doistipos de bancos de dados e, para isso, é necessário configurar os bancos de dados a seremconsultados através de um dicionário de dados, que tem a finalidade de armazenar osmetadados de conexão, como o nome do banco de dados, nome de usuário, senha, portade comunicação, além de outros elementos necessários para realizar consultas.

O funcionamento do middleware é ilustrado por meio de uma consulta nosbancos de dados Oracle e Cassandra, relacional e NOSQL respectivamente. A consultafornecida é 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 eoutros 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 estruturafoi 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 paraverificar 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 dadosenvolvido na consulta. Em razão de bancos de dados NOSQL não fornecerem padrões deconsultas, o módulo SQL engine realiza a conversão de um comando SQL para o padrãoaceito em bancos de dados NOSQL. O SQL processor é responsável por preparar, analisare enviar para os bancos de dados o comando SQL solicitado. O Result Set Handler recebeos resultados parciais gerados em cada banco de dados e apresenta o resultado de formaunificada.

Os resultados produzidos neste trabalho tem o objetivo de avaliar o desempenhode uma aplicação sem a utilização do método proposto e com a utilização do métodoproposto, 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 nestetrabalho: na cláusula select da consulta SQL inicial, os atributos devem ser escritos noformato relação.atributo. No método proposto neste trabalho, pode-se informar apenas oatributo. Além disso, o método proposto neste trabalho permite executar consultas envol-vendo 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 dedados NOSQL.

O trabalho de Lawrence [17] aborda a integração de dados entre bancos de dadosrelacionais 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 dedados e executar a consulta. Para uma consulta em banco de dados relacional é aplicadoum 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 daconsulta. 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 dadosMySQL e MongoDB, são criadas novas consultas SQL para cada relação informada naconsulta inicial. Essas consultas são executadas separadamente em cada fonte de dadoscom o auxilio da API JDBC. Para processar o resultado final da consulta, se as relaçõesda consulta de entrada estiverem armazenadas no banco de dados MySQL, a consulta deentrada é executada neste banco de dados. Se as relações da consulta de entrada estiveremarmazenadas no banco de dados MongoDB, a consulta é executada neste banco de dadose 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 bancode dados, por exemplo: select nome from mysql.Cliente. A maneira como é realizadaa conexão com os bancos de dados e possíveis metadados utilizados para executar aconexão não são explicados pelo autor. Neste aspecto, há uma diferença entre o trabalhode 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ãoarmazenadas.

A avaliação desta proposta foi realizada por meio de operações de consulta nosbancos 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 umaumento 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 naoperação de inserção, em que obteve um resultado maior em relação ao tempo de consultautilizando o método proposto.

2.2 Integração de dados entre bancos de dados relacio-nais e outras fontes de dados

Alguns métodos para integração de dados entre diferentes fontes de dados sãopropostos por diversos autores, mas não abordam especificamente bancos de dados


relacionais e NOSQL. Entretanto, é relevante mensionar alguns trabalhos que propõeintegração de dados com outras fontes de dados, a fim de apresentar técnicas que foramutilizadas para realizar a integração e que foram aplicadas no método proposto nestetrabalho.

O trabalho de Kozlova et al. [16] aborda o processamento integrado de consultasem bancos de dados relacionais e bancos de dados XML. O método proposto é cons-truído com base em outro trabalho desenvolvido pelos mesmos autores, em que foi imple-mentada uma ferramenta chamada SQXML para validar o método proposto. O problemaaborda 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ânciade se construir uma visão, com base nos bancos de dados, para cada tipo de informaçãogerada no processamento da consulta. O método é capaz de converter um comando SQLinicial em novas consultas no formato XML ou SQL, que são encaminhadas para cadabanco de dados de dados. Os resultados obtidos em cada banco de dados são tratados pelométodo proposto a fim de apresentar uma única resposta.

O funcionamento do método estabelece a seguinte lógica: a partir da consultainicial, um módulo denominado Query Process Component executa os procedimentospara identificar os atributos e as relações. Em seguida, são construídas novas consultasSQL, uma para cada banco de dados, para serem utilizadas na construção da visão SQL eXML. As consultas construídas são convertidas no formato SQL e XQuery e são enviadaspara cada banco de dados. Os resultados obtidos em cada banco de dados são retornadospara o componente Query Process Component. Os resultados obtidos em um banco dedados XML são enviados para uma relação temporária em banco de dados relacional. Nofim 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 geradospelas aplicações e os diferentes tipos de bancos de dados existentes que manipulam osdados.

Os autores propõem um middleware que é capaz de interagir com vários bancosde dados e realizar a integração de dados entre bancos de dados relacionais e fontes dedados XML. No entanto, os autores citam alguns desafios que são encontrados ao tentarresolver 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 dedados requer um modelo de dados em comum para facilitar a manipulação de diferentestipos de dados; o ambiente do usuário é dinâmico; várias soluções de integração de dadosnecessitam de interação com o usuário.

Para permitir que os bancos de dados sejam acessíveis, o método permite oregistro de metadados de conexão dos bancos de dados (XML ou relacional). Para bancosde dados relacionais, são aceitos os metadados: tipo (relacional ou XML), nome do


SGBD, nome do banco de dados, endereço IP, porta de comunicação, usuário e senha dobanco de dados. Para bancos de dados XML, são aceitos os metadados: tipo (relacionalou XML), nome do documento XML que representa o banco de dados, endereço IP doservidor.

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, atri-butos 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 transformadasno 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 emfontes XML, é feita a transformação da consulta no padrão da linguagem XQuery. Apósesses procedimentos, os resultados obtidos em cada consulta são integrados em um únicoresultado final através de um documento XML.

O trabalho de Calil e Dos Santos [4] aborda a execução de comandos DML (in-serir, 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 ummapeamento dos elementos que compõe a estrutura de um banco de dados relacional paraa estrutura do banco de dados SimpleDB. Esse mapeamento é utilizado em vários proces-sos para converter um elemento SQL em um elemento do banco de dados SimpleDB.

Estrutura relacional e SimpleDBRelacional 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 rela-cional para o banco de dados SimpleDB [4].

A Tabela 2.1 apresenta o mapeamento desenvolvido pelos autores para relacionaros 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 quecompõ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, queretorna um resultado em formato de tabela, e ExecuteNonQuery, que retorna um


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 primeirométodo. A operação de consulta permite a utilização de junção, mas não permiteagrupamento e subconsultas. Se a consulta é composta por junção, os atributosdevem ser precedidos pelo nome da relação (ex.: relação.atributo).

• Command Decomposition: este processo é responsável por segmentar o comandoSQL e converter os elementos SQL para o formato do SimpleDB. Para uma ope-ração de consulta, são extraídos os elementos: atributos, relações, junções e pre-dicados, porém, os autores não comentam onde são armazenados esses elementostemporariamente.

• Processing and Return: este processo é responsável por executar o comando SQLno SimpleDB. Em operações de consulta, se houver mais de uma relação referenci-ada através de junção, são criadas novas consultas, uma para cada relação da con-sulta inicial, composta pelos atributos e condições específicas de cada relação. Osresultados processados em cada relação são mesclados usando as chaves estrangei-ras 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 grandevolume de dados. Na consulta, é avaliado o tempo gasto para executar diferentes consultasem termos de complexidade.

• Nas operações de consulta, houve um aumento de aproximadamente 40% no tempode processamento, em comparação ao tempo gasto em executar diretamente noSimpleDB. De acordo com os autores, era esperada essa diferença no tempo, poiso método proposto processa dados consultados em bancos de dados nas nuvens econverte para o esquema relacional.

• Nas operações de inserção, houve um aumento de aproximadamente 5% no tempode processamento, em comparação ao tempo gasto em executar diretamente noSimpleDB. De acordo com os autores, esse aumento no tempo não é um obstáculopara adotar o método proposto.


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 cha-mado SimpleDB, utilizando a linguagem de consulta SQL. Os autores citam a necessidadede se utilizar os recursos oferecidos pela linguagem de consulta SQL em conjunto aos re-cursos 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 executaros dois tipos de comandos SQL, tanto DML quanto DDL.

O método desenvolvido em [10] é chamado de SimpleSQL e pode receber umcomando DDL, converter para a estrutura do banco de dados SimpleDB e executar ocomando. Para isso, a estrutura de um banco de dados relacional é mapeada para aestrutura do banco de dados SimpleDB, conforme a Tabela 2.1.

Para iniciar a execução do método, o comando DDL é recebido pelo móduloAccess Inteface, que é responsável por identificar o comando SQL. Após esse procedi-mento, o módulo Command Translation identifica o banco de dados, relações, colunas erestrições do comando inicial a fim de mapear os elementos SQL para o SimpleDB. Deacordo 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 elemen-tos correspondentes para o SimpleDB. Por fim, o módulo Processing and Return recebeos dados e o comando a ser processado e os envia ao SimpleDB. O resultado da operaçãoexecutada é encaminhada para o módulo Access Interface e posteriormente enviada paraa 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 processamentoda execução de comandos DDL com a utilização do método proposto. Os resultadosapontam 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


operações de criação de relações, por exemplo, houve um aumento no tempo de execuçãodo comando, porém, inferior a 34%, em comparação ao tempo de execução do comandono SimpleDB. Em operações de atualização e exclusão de relações, o tempo de execuçãodos 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 pramanipular dados.

É proposto um mecanismo em que é submetida uma consulta SQL para serexecutada por bancos de dados NOSQL. O método proposto permite a execução apenasde consultas e em apenas um banco de dados NOSQL, no caso, HBase. Para controlaro 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 nobanco 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 dascolunas 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 queofereç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 SQLcontendo 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 consultasutilizando o método proposto, Hive e MySQL. Os experimentos foram executados em umambiente contendo dados entre 100GB e 700GB de tamanho, utilizando consultas comselect, between, like, group by, group by, order by e join. De acordo com os resultadosobtidos, o método proposto supera, em tempo de execução das consultas, o Hive eMySQL, em todas as consultas, exceto as consultas envolvendo join, sendo inferior apenasao MySQL.

O trabalho de Duggan et al. [11] aborda uma nova visão de bancos de dadosfederados com a crescente necessidade de gerenciamento de informações que abrangevários modelos de dados.


A partir dos trabalhos relacionados com a proposta deste trabalho, foi criada umatabela que apresenta algumas caracteristicas que diferenciam os trabalhos apresentadosnesta seção e o método proposto neste trabalho.


Ace

ssa

vári

osba

ncos

Util

iza

JDB

CU

sam

etad

a-do

sC

onhe

cim

ento

prév

ioB

DC

onhe

cim

ento

prév

iore

la-

ção

Vár

ias

cate

gori

asN

OSQ

L

Con

sulta

pré-

proc

essa

da

Perm

iteJo

inE

lem

ento

sde

agre

gaçã

o(s

um,

coun

t...)

Zha

nget

al.

[45]

Sim

Sim

Sim

Não

Sim

Não

Não

Não

Não

Law

renc

e[1

7]Si

mSi

mSi

mSi

mN

ãoN

ãoN

ãoSi

mSi

m

Koz

lova

etal

.[16

]Si

mN

ãoN

ãoN

ãode

finid

oN

ãode

finid

oN

ãode

finid

oN

ãoN

ãode

finid

oN

ãode

finid

o

Suet

al.[

38]

Sim

Não

Sim

Não

defin

ido

Não

defin

ido

Não

Sim

Não

defin

ido

Não

defin

ido

Cal

ile

Dos

Sant

os[4

]N

ãoN

ãoN

ãode

finid

oN

ãode

finid

oSi

mN

ãoN

ãoSi

mN

ão

Dos

Sant

oset

al.[

10]

Não

Não

Não

defin

ido

Não

defin

ido

Sim

Não

Não

Sim

Não

Chu

nget

al.

[9]

Não

Sim

Sim

Não

Não

Não

Não

Sim

Sim

Mét

odo

pro-

post

o20

15Si

mSi

mSi

mN

ãoN

ãoSi

mN

ãoSi

mSi

m

Tabe

la2.

2:C

arac

terí

stic

asdo

str

abal

hos

rela

cion

ados


A Tabela 2.2 apresenta os elementos que foram utilizados para comparar ostrabalhos 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 dadosa partir da consulta de entrada.

• Utiliza JDBC: o método proposto utiliza driver JDBC específico de cada banco dedados envolvido na consulta de entrada.

• Usa metadados: o método proposto utiliza o mecanismo de configuração prévia demetadados de conexão.

• Conhecimento prévio BD: o método proposto identifica o banco de dados quemantém uma relação a partir de um indicativo do banco de dados (nome do bancoou 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 doatributo com o nome da relação a qual pertece.

• Várias categorias NOSQL: o método proposto permite acessar várias categoriasde 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 3Fundamentação teórica

Este capítulo apresenta os conceitos, estruturas e modelos de bancos de dadosrelacionais, bancos de dados NOSQL e outros assuntos necessários ao entendimento destetrabalho.

3.1 Modelo relacional

Por se tratar de um modelo de dados bastante testado, documentado e fundamen-tado, não será feita uma abordagem profunda nas teorias do modelo relacional.

O modelo relacional é caracterizado por descrever os dados em uma estruturachamada esquema. No modelo relacional, o esquema especifica as relações, os atributo eo 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 emmúltiplas relações, permitindo executar consultas relacionando várias relações através dejunções [28], [15]. Os bancos de dados que são originados desse modelo são conhecidoscomo bancos de dados relacionais.

Os bancos de dados relacionais utilizam a linguagem de consulta SQL, quepermite o acesso e a manipulação de dados. A linguagem de consulta SQL contémelementos que permitem a criação, alteração, exclusão e consulta de dados nos bancosde dados. Além disso, fornece uma sintaxe padrão que auxilia o acesso e manipulaçãodos dados [31], [15].

Um dos recursos importantes do modelo relacional, e que o difere de outrosmodelos, 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 integridadedos 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 emsistemas bancários, em que se deve garantir a integridade dos valores gerados por umatransaçã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 dosdados, 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 comofonte de armazenamento. De acordo com Leavitt [18] e Mohamed et al. [21], a abordagemrelacional é utilizada em aplicações de negócios, tais como: bancos, indústrias, empresascomerciais, em que é necessário obter informações com garantia da consistência dosdados e consultas com as características citadas.

Existem, entretanto, algumas limitações na utilização de bancos de relacionaisno armazenamento de dados. Os bancos de dados relacionais não são adequados paralidar 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 seremarmazenados no banco de dados, devem ser convertidos para estrutura de relações. Essatarefa se torna difícil e lenta em bancos de dados relacionais, por se tratar de uma estruturacom um esquema defido. A escalabilidade da aplicação se torna inviável, por distribuir osdados 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çãode bancos de dados relacionais em alguns tipos de aplicações: (1) o conjunto de dadosdisponíveis para ser acessado é cada vez maior; (2) a disponibilidade da aplicação; (3) ostipos 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 anosde 2007 e 2010 aumentou em vinte e cinco vezes. A Figura 3.1 apresenta os tipos dedados 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, como 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 geradosdados como ontologias, RDF e outros.

Tauro et al. [39] ainda abordam o problema em utilizar bancos de dados relacio-nais na manipulação de dados semi-estruturados. Os bancos de dados relacionais possuemuma 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]. Dadossemi-estruturados são dados que possuem atributos não definidos e opcionais. À medidaque as informações aumentam, é necessário aumentar, por exemplo, o número de colunasde uma relação.

3.2 Abordagem NOSQL

A abordagem NOSQL foi proposta com o objetivo de oferecer novas maneirasno armazenamento de dados com ênfase no armazenamento de grandes massas dedados, disponibilidade e escalabilidade da aplicação [25]. Essa abordagem foi propostainicialmente em 1999 por Carlos Strozzi, no entanto, passou a se tornar mais conhecidaa partir de 2009, através de Johan Oskarsson, em um evento que discutia bancos dedados distribuídos e open-source [45]. Desde então, empresas como Google, Facebooke Amazon passaram a desenvolver suas próprias soluções NOSQL.

Os bancos de dados NOSQL são representados em uma estrutura denominadaesquema, porém, não é necessário sua definição prévia [40]. Nessa abordagem, os dadossão armazenados como um par chave-valor, em que a chave é única e identifica o registroe 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 dosdados. Alguns bancos de dados NOSQL oferecem a escalabilidade horizontal, em que osdados são distribuídos em computadores com menor poder de processamento, em vez deserem distribuídos em um único servidor com maior poder de processamento. Em algunscasos, bancos de dados NOSQL permitem melhor desempenho de processamento deoperações SQL em comparação com bancos de dados relacionais e se tornam adequadosem aplicações que manipulam grandes volumes de dados, na ordem de zetabytes oupetabytes [18] [33], [8], [25].

Tudorica e Bucur [40] abordam as principais características e categorias dosbancos de dados NOSQL. Estes bancos de dados não oferecem relacionamentos entreos 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


de inserção, alteração, exclusão e consulta de dados. De acordo com as pesquisas, foiconstatado que grande parte dos bancos de dados NOSQL são open-source. SegundoLawrence [17], bancos de dados NOSQL foram desenvolvidos para suprir os recursos queo modelo relacional não oferece, frequentemente envolvendo recursos de processamentode 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 paraarmazenar 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 chave-valor, 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 eBucur [40], Cattell [8], Hecht e Jablonski [14], Han et al. [13] são alguns dos autores queabordam 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 valoresocorrem através das chaves [13]. Uma determinada pesquisa pode ser feita apenaspela 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 ummecanismo de armazenamento: replicação, versionamento, transações, ordenação eoutros recursos [8], [14].De acordo com [14], por se tratar de um modelo de dados simples, as APIs deconsulta disponíveis para esta categoria não fornecem tantos recursos quanto asde outras categorias NOSQL, fornecendo apenas os métodos: put, get e delete.Se é necessário realizar algum tipo de consulta mais complexa, esta deve serimplementada na aplicação. Portanto, a categoria chave-valor não deve ser utilizadaem casos que envolva consultas complexas. A Figura 3.2 exemplifica a estrutura dacategoria 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


Figura 3.2: Estrutura do banco de dados chave-valor

Este modelo armazena um par chave-documento em um documento JSON ouXML. Em cada documento, a chave que identifica um valor deve ser única econtém uma chave especial chamada ID, que também é única, que identificao documento explicitamente dentro de uma coleção de documentos [14]. Umacoleção de documentos compõe um banco de dados. Em cada banco de dados, pode-se ter tipos diferentes de documentos, documentos aninhados e permite a criação deíndices secundários [8]. CouchDB, MongoDB, OrientDB, RavenDB são exemplosde bancos de dados NOSQL orientados a documentos [40], [8]. Para exemplificar aestrutura dos bancos de dados orientados a documentos, será utilizado o banco dedados MongoDB.

Figura 3.3: Estrutura do banco de dados MongoDB [43]

A Figura 3.4 apresenta a estrutura de armazenamento do MongoDB. Os documen-tos são compostos por vários atributos, porém, cada atributo é composto apenaspelo seu valor.MongoDB é um banco de dados escrito na linguagem C++ e possui algumascaracterísticas: a chave que identifica um documento normalmente é a combinaçãodo ID e um valor timestamp; implementa uma linguagem própria de consulta;


oferece técnicas de distribuição de documentos em vários servidores através dareplicação de dados, permitindo master-slave, que é mais utilizado em caso defalha 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 estruturabásica do banco de dados MongoDB.

Figura 3.4: Exemplo da estrutura de armazenamento do Mon-goDB

Na abordagem relacional, alguns termos são utilizados para identificar os elementosque compõe a estrutura dos bancos de dados relacionais. É possível fazer umaanalogia com o MongoDB e mostrar a terminologia empregada nos elementos quecompõe a estrutura do banco de dados.

Termos SQL Termos MongoDBBanco de dados Banco de dadosTabela ColeçãoLinha Documento ou JSONColuna CampoIndex IndexPrimary Key Primary key

Tabela 3.1: Comparação dos termos utilizados em bancos de da-dos relacionais e MongoDB [22]

A Tabela 3.1 apresenta os termos que são empregados em elementos dos bancosde dados relacionais e seus correspondentes no banco de dados MongoDB. Algunstermos, tais como index, primary key e banco de dados tem o mesmo significado emambos, 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 dedados em comparação aos bancos de dados relacionais. É possível realizar umacomparação sintática de como é feita a criação de uma relação, inserção e consultados dados em um banco de dados relacional e no banco de dados MongoDB.


A Figura 3.5 apresenta uma comparação sintática para criação de uma relação emum banco de dados relacional e a criação de uma coleção de documentos no bancode dados MongoDB. Ao criar uma relação chamada users em um banco de dadosrelacional, é necessário definir o tipo de dado e outros atributos. No banco de dadosMongoDB, 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 embanco de dados relacional e MongoDB [22]

A Figura 3.6 apresenta a sintaxe utilizada para inserir dados em uma relação dobanco de dados relacional e em um documento no banco de dados MongoDB. Parainserir dados em um banco de dados relacional, é possível utilizar uma relaçãoque foi criada, mas não utilizada no momento da criação. No banco de dadosMongoDB, pode-se utilizar uma coleção de documentos já criada ou informar onome da coleção de documentos no momento da inserção dos dados.

Figura 3.6: Comparação da sintaxe de inserção de dados embanco de dados relacional e MongoDB [22]

A Figura 3.7 apresenta a sintaxe para consultar dados em um banco de dadosrelacional e em um documento no banco de dados MongoDB. É possível verificarque o banco de dados MongoDB não utiliza a linguagem SQL para consulta dedados, mas sim, uma API que realiza as operações com o banco de dados. Assimcomo a linguagem SQL oferece a operação select, o banco de dados MongoDBoferece o método find(), que tem a tarefa de pesquisar os dados dentro de umacoleção de documentos.


Figura 3.7: Comparação da sintaxe de consulta em banco de da-dos relacional e MongoDB [22]

3. GrafosBancos de dados orientados a grafos são especializados em gerenciar dados forte-mente ligados. Para aplicações baseadas em dados com relacionamentos, tais comomapas, serviços de localização, é recomendada a utilização desta categoria de bancode dados NOSQL [14].Nesta categoria, os nós e arestas consistem de objetos com atributos chave-valorembutidos. A quantidade de pares <chave, valor> é definida pelo esquema do bancode dados, em que uma expressão que envolva restrições de maior complexidadepode ser descrita facilmente [14].Em contraste com outras categorias NOSQL, a categoria NOSQL orientado a grafosoferece algumas linguagens de consulta, tais como SPARQL e Gremlin. Entretanto,exemplos de bancos de dados que apoiam essas linguagens de consulta são Neo4Je GraphDB, diferente do FlockDB, que não apoia a utilização destas linguagens deconsulta [14].Um caso de utilização da categoria NOSQL orientado a grafos é o Twitter. A redesocial armazena vários relacionamentos entre os usuários a fim de fornecer o serviçode pesquisa de tweets. É utilizado o banco de dados FlockDB para armazenar osrelacionamentos, e, de acordo com [14], é um banco de dados mais simples emcomparação a outros da categoria NOSQL.Neo4J, InfoGrid, HyperGraphDB, VertexDB são exemplos de orientado a grafos[40].

4. Colunas


A categoria banco de dados orientado a colunas é o modelo que mais se assemelhacom bancos de dados relacionais, que armazena as informações em relações, masnão permite relacionamentos entre elas. Os dados são armazenados separadamenteem colunas e cada coluna de dados é um índice do banco de dados. As colunaspodem ser agrupadas em famílias de colunas, que permitem sua distribuição emvá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 exemplosde bancos de dados orientados a colunas [40]. Para exemplificar a estrutura dosbancos de dados orientados a colunas, será utilizado o banco de dados Cassandra.Cassandra é um banco de dados escrito em Java, desenvolvido pelo Facebook epossui algumas características: permite armazenar dados estruturados, semi estru-turados e não estruturados; projetado para armazenar grande quantidade de dados.Quando, em algum cluster, algum nó é adicionado ou removido, os dados são dis-tribuídos automaticamente em todos os nós do cluster [1].

Figura 3.8: Estrutura de armazenamento do banco de dados Cas-sandra

A Figura 3.8 exemplifica a estrutura de armazenamento do banco de dados Cas-sandra. É possível identificar que o keypace é responsável por armazenar toda aestrutura de armazenamento. Uma família de colunas é composta por linhas e cadalinha é formada por colunas e um atributo chave. Em analogia a bancos de dadosrelacionais, o keyspace é equivalente ao banco de dados, uma família de colunasequivale a uma relação e uma coluna é comparada a um atributo [1].O Cassandra oferece uma linguagem de consulta própria chamada CQL (CassandraQuery Language), que se assemelha à linguagem SQL, que utiliza o mesmo con-ceito de estruturação das relações em linhas e colunas [7]. A linguagem CQL não


oferece algumas operações com banco de dados, tais como: junções, subconsultas,agrupamentos e outras operações [7].

Comandos CQLSELECT * FROM users WHERE firstname = "jane"and last-name="smith";SELECT * FROM emp WHERE empID IN (130,104) ORDERBY deptID DESC;SELECT * FROM emp where empID IN (130,104) ORDER BYdeptID ASC;SELECT artist, venue FROM playlists WHERE venue CON-TAINS "The Fillmore";

Tabela 3.2: Exemplos de consultas utilizando o CQL [7]

A Tabela 3.2 apresenta exemplos de consultas utilizando a linguagem CQL. Acláusula select permite operações com nomes de atributos, count(*), distinct eutilização de alias com a expressão as. Na cláusula where, é permitida a utilizaçãodos elementos: and, in, contains, =, <, >, <=, >=. Na cláusula order by, é permitidoordenaçã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ãodisponí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 Cas-sandra utilizando a linguagem CQL. A estrutura é semelhante à linguagem SQL,podendo conter atributos com os seguintes tipos: ascii, bigint, blob, boolean, coun-

ter, decimal, double, float, int, text, timestamp, uuid, varchar, varint [6].A linguagem de consulta CQL é, ainda, bastante estudada e modificada. O site daAPI, 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 dasversões, não sendo possível afirmar se um determinado recurso estará presente ouconterá o mesmo nome ou funcionamento da versão anterior.


3.2.3 Outras características da abordagem NOSQL

Tudorica e Bucur [40] comentam que algumas categorias de bancos de dadospossuem características da abordagem NOSQL, porém, oferecem alguns recursos debancos 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 quandoabordam o assunto NOSQL. Essas outras categorias são: bancos de dados orientado aobjetos, 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 origemda fundamentação da abordagem. Nesse estudo, foi discutido que a abordagem NOSQLé baseada nas propriedades CAP, que é o acrônimo de consistência, disponibilidade etolerância a partição. Essas propriedades foram fundamentadas em 2000, pelo professorEric Brewer, com a construção do teorema CAP. De acordo com ele, em ambientesdistribuí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, CTe DC. O centro da figura é apresentado sem nenhum indicativo, demonstrando que nãoexiste 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, entrevários temas, a fundamentação da abordagem NOSQL por parte do teorema CAP, fazendoanalogias com as propriedades ACID da abordagem relacional.

De acordo com Tauro et al. [39], a principal vantagem da abordagem NOSQL emrelação à abordagem relacional é a facilidade em manipular dados não estruturados, comodocumentos, emails, dados multimídia, dados gerados em redes sociais. Os principais re-cursos 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, aumen-tou também a quantidade de dados gerados pelas aplicações, e esses dados podem ser do


tipo estruturado, semi-estruturado ou não estruturado. Processar esses dados requer altavelocidade, esquema de dados flexível e bancos de dados distribuídos. De acordo com osrecursos oferecidos, a abordagem NOSQL é a mais indicada para esses cenários.

Leavitt [18] aborda em seu trabalho o tema: organizações que trabalham comgrande quantidade de dados não estruturados estão, cada vez mais, migrando para bancosde dados NOSQL. É feito um estudo apontando as principais limitações da abordagemrelacional e os motivos pelas quais várias empresas passaram a utilizar bancos de dadosNOSQL no armazenamento de dados. Entre os principais motivos, estão: rápido acessoaos dados, modelo de dados simples, escalabilidade horizontal, bancos de dados open-

source. O autor comenta que os bancos de dados NOSQL não vão substituir os bancos dedados relacionais, mas sim, oferecer recursos diferentes para serem implementados emoutros 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 NOSQLem relação ao tempo e velocidade de execução de operações com o banco de dados.

Bancos de dados No de operações10 50 100 1000 10000 100000

MongoDB 61 75 84 387 2693 23354RavenDB 570 898 1213 6939 71343 740450CouchDB 90 374 616 6211 67216 932038Cassandra 117 160 212 1200 9801 88197Hypertable 55 90 184 1035 10938 114872Couchbase 60 76 63 142 936 8492

MS SQL Express 30 94 129 1790 15588 216479

Tabela 3.3: Comparação do tempo de inserção entre bancos dedados 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 6bancos de dados NOSQL e 1 banco de dados relacional.

Com 10 operações, o banco de dados MSSQL Express se mostrou mais rápidoque todos os outros bancos de dados. Porém, com 100.000 operações, o banco de dadosCouchbase obteve um resultado de tempo de escrita melhor, seguido pelo MongoDB eCassandra. De acordo com os autores, nos testes de leitura e escrita, foram constatadosque 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çãode í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 tempode 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, emmilissegundos, de execução das operações. O resultado aponta que o tempo de consultano banco de dados SQL é maior que no MongoDB. De acordo com os autores, isso se deveao fato do MongoDB utilizar campos indexados, no caso ID, e também por processar asconsultas em memória.

Wei-ping et al. [43] apresentam o resultado das análises realizadas nos bancosde dados MongoDB e MySQL ao executar operações SQL. O resultado foi obtido atravésde duas operações, sendo uma operação de inserção e outra de consulta. Na inserção, obanco de dados MongoDB apresentou um tempo mais satisfatório que no MySQL. Naconsulta, os dois bancos de dados obtiveram um tempo menor que na inserção, porém, oMongoDB também alcançou um tempo menor que o MySQL.

Os resultados apresentados acima indicam que as operações realizadas em ban-cos de dados NOSQL são mais rápidas do que em bancos de dados relacionais. No en-tanto, 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 quan-tidade de dados envolvidos no processo, o tipo dos dados gerados pela aplicação, o tipoda aplicação, as operações que os usuários necessitam e quais os recursos que o banco dedados pode oferecer. Por exemplo: alguns desses testes podem ter sido gerados em umaaplicação que realmente faz uso de bancos relacionais, e, de fato, obteve um resultadomenos satisfatório do que os bancos NOSQL. Entretanto, para os usuários e os resultadosesperados pela aplicação, o tempo de resposta da operação pode ser irrelevante, visto quepodem ter outros recursos que são oferecidos pelos bancos de dados relacionais e consu-midos 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 vezmais diversificados nos últimos anos, devido ao fácil acesso à Web e a disponibilidadede armazenar dados com baixo custo [19]. No entanto, existem situações nas quaissão disponibilizados formulários de cadastros para interação com o usuário ou sãoarmazenados os metadados de dados manipulados pelos usuários [3]. Em geral, os dadospodem residir em registros com estrutura definida, que são classificados como dadosestruturados, ou em arquivos contendo texto, música, gráficos, que são classificados comodados não estruturados [12].

A Tabela 3.4 apresenta a forma como é representado um dado estruturado. Oexemplo 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 ContatoAtributo Tipo Valor

Nome Texto José PereiraEndereco Texto Rua das flores, no 5

Cidade Texto São PauloBairro Texto Jardim das FloresIdade Numero 35

Tabela 3.4: Exemplo de dados estruturados

mesmas características, tipos de dados definidos e mesma quantidade de atributos, emcomparação, por exemplo, a dados encontrados em documentos de texto. Independente dapessoa 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 tornaadequado armazenar esses dados em bancos de dados relacionais [28]. Dados estruturadossão dados armazenados em uma estrutura predefinida e que podem ser organizadas emrelaçõ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 umdocumento de texto. Neste exemplo é utilizada a localização da palavra "consulta", emque é possível verificar que todas as palavras e expressões não possuem uma estruturadefinida, sendo distribuídas livremente no texto.

O conceito de dados não estruturados pode ter vários significados dependendodo contexto em que está sendo empregado. Blumberg e Atre [3] argumentam que nocontexto de bancos de dados relacionais, dados não estruturados são dados que não podemser armazenados em linhas e colunas. Em vez disso, os dados devem ser armazenadosnum tipo BLOB (binary large object). No contexto de dados gerados e consumidos poraplicaçõ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ãooferecem 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 pordata, hora ou tamanho. Se o email fosse totalmente estruturado, seria possível organizartambém por assunto ou conteúdo.

3.4 Metadados

Metadados são considerados "dados sobre dados"[20], [30], ou seja, dados quedescrevem dados. Os metadados descrevem, localizam, explicam um dado, o que tornapossível a recuperação e gerenciamento dos dados [30]. Por exemplo: em um sistemagerenciador de bancos de dados, se uma pessoa deseja conhecer o domínio, os bancos dedados criados, as relações em cada banco de dados, deve-se recorrer ao catálogo do bancode 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 encontraruma 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 ometadado 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óveldescrevem a localização da casa.

Os metadados podem ser classificados em três categorias [30]: (1) metadadosdescritivos descrevem recursos com o objetivo de identificar e recuperar informaçõesatravés de elementos, tais como: título, autor, palavras-chave; (2) metadados estrutura-dos descrevem como os objetos são compostos e suas relações. Por exemplo: o esquemado banco de dados [34]; (3) metadados administrativos fornecem informações que auxi-liam o gerenciamento de recursos, tais como controle de permissões de acesso, localizaçãode arquivos [34].

Configuração do banco de dadosElemento ValorNome do banco de dados VendasNome do usuário UserSenha 123456IP do servidor 192.168.1.1Porta de comunicação 1433Banco de dados MSSQL ServerData da criação 19/11/2011

Tabela 3.5: Exemplo de metadados

A Tabela 3.5 apresenta um exemplo de metadados estruturados, modelo utilizadoneste trabalho. A partir dos dados configurados, é possível identificar que existe uma basede 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 ea porta de comunicação 1433, ou seja, o conjunto de metadados descreve a maneira paratornar 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ãocom os bancos de dados é uma tarefa difícil, pois cada um deles disponibiliza recursosdiferentes para receber as conexões da aplicação, o que torna inviável o estudo de todosos bancos de dados e a maneira em que é feita a conexão, proporcionando um alto graude complexidade no desenvolvimento de aplicações [46]. Nesse contexto, é importanteum mecanismo que ofereça um tipo de conexão padrão com todos os bancos de dados eassuma as tarefas de realizar as operações.

JDBC (Java Database Connectivity) é uma API desenvolvida na linguagemJava 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 coma aplicação através de uma linguagem unificada de acesso a dados. Esse conjunto deelementos é 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 dedriver contém características e mecanismos diferentes de comunicação com o banco dedados [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.


• A primeira categoria consiste de um mecanismo em que são necessários doisdrivers, 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çãolocal, e é utilizada para comunicar com o banco de dados cliente. São instaladosdrivers específicos nos computadores locais (como driver ODBC), e o driver JDBCna aplicação transforma as requisições de acesso ao banco de dados no padrão daAPI local.

• A terceira categoria é chamada de middleware. Nessa categoria, não é necessário ainstalação de qualquer outro tipo de driver, porém, o driver deve ser instalado noservidor de banco de dados. O middleware é responsável por realizar as conversõesnecessárias para o acesso ao banco de dados.

• A quarta categoria é o driver JDBC Java puro. Nessa categoria, os drivers se comu-nicam diretamente com o banco de dados, o que proporciona uma independência deplataforma de desenvolvimento. Assim como na terceira categoria, não é necessárioa instalação de drivers adicionais para a execução de comandos com os bancos dedados.

Para utilizar a API JDBC em uma aplicação, o desenvolvedor deve, primeira-mente, 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 apoiara comunicação das aplicações com os bancos de dados. Wiley [44] diz que uma das prin-cipais 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 daaplicação.

A Figura 3.13 apresenta um exemplo em que a API JDBC é utilizada entre aaplicação e o banco de dados. O núcleo da API JDBC é composto pelo driver JDBC, queimplementa todas as classes e interfaces para conectar e manipular os dados no banco dedados. Através dos métodos criados no driver JDBC, é construída a conexão para o bancode dados a ser acessado [44]. A camada driver manager é responsável por gerenciar osdrivers 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êsprocedimentos principais [44]: (1) estabelecer a conexão entre a aplicação e o banco dedados, em que é necessário informar os metadados para realizar a conexão; (2) construire 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 docomando SQL, a API JDBC recebe o resultado da operação executada pelo banco dedados no formato de tabela, contendo linhas e colunas.


Figura 3.13: Exemplo da arquitetura JDBC [44]

Alguns bancos de dados NOSQL também fornecem driver JDBC [17]. Isso é umaspecto positivo para resolver parte dos desafios identificados durante a pesquisa, pois, setanto 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 dedados.

3.5.1 Driver JDBC para Cassandra

A linguagem de consulta do banco de dados Cassandra, chamada CQL, possuiuma estrutura sintática que se assemelha à linguagem SQL, como foi comentado anteri-ormente. Entretanto, a semântica implementada na linguagem CQL é diferente da lingua-gem SQL. Para atender as necessidades do presente trabalho, é importante que a lingua-gem CQL tenha um comportamento similiar à linguagem SQL, resultando assim em umaestrutura única de acesso aos dados. O Cassandra fornece uma API JDBC [5], que é umaextensão da API JDBC padrão, e oferece mecanismos para realizar operações com bancode dados (conexão com banco de dados, criação de relações, consultas e etc.), utilizandoos recursos que são oferecidos pela arquitetura JDBC, através da sintaxe da linguagemSQL.

A responsabilidade da API JDBC do Cassandra é realizar o mapeamento paraconverter a estrutura da consulta SQL na estrutura da linguagem CQL, fornecer umainterface unificada de acesso aos dados e permitir enviar uma consulta SQL para o banco


de dados Cassandra. As validações de possíveis elementos que podem estar contidos naconsulta SQL, mas que não são reconhecidos pelo Cassandra, é de responsabilidade doCassandra. 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 eenvia 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ãosendo possível afirmar se uma determinada funcionalidade disponível em uma versãoestará disponível em outras versões posteriores. Portanto, as versões do driver JDBCpodem 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 dadosem relação à estrutura da linguagem SQL e da linguagem CQL. Isso se deve ao fatode possuir uma estrutura diferente da abordagem relacional e da abordagem NOSQLorientado a colunas. No entanto, é possível encontrar o driver JDBC para o MongoDBque proporciona um mecanismo de acesso aos dados utilizando a sintaxe SQL [23].

Da mesma maneira como é realizado no banco de dados Cassandra, a responsa-bilidade do driver JDBC para o MongoDB é mapear a estrutura do comando SQL paraa estrutura do banco de dados MongoDB, possibilitando um mecanismo de acesso unifi-cado aos dados. Ao executar a consulta, o MongoDB tem a responsabilidade de recebera 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 dedados retornará uma mensagem informando o motivo pelo qual não foi possível executara consulta SQL.

CAPÍTULO 4Um método para integração de dadosarmazenados em bancos de dados relacionais eNOSQL

Neste capítulo é apresentado um método desenvolvido para integração de da-dos armazenados em bancos de dados de diferentes abordagens distribuídos em váriosservidores. O método é capaz de executar consultas sem o prévio conhecimento sobre alocalizaçã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 inspiradoem [45], em que a partir de uma consulta de entrada escrita nos padrões da linguagemde consulta SQL, várias outras consultas correspondentes são construídas, sendo umapara cada relação que compõe a consulta SQL de entrada. Isso se deve ao fato de que asrelaçõ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 submetidasseparadamente aos respectivos bancos de dados. Os resultados parciais gerados em cadaconsulta são armazenados em um único banco de dados relacional temporário, contendoas relações e atributos de cada consulta. O resultado final é gerado através da submissãoda 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 dosbancos de dados nos quais estão armazenados os dados relevantes para o resultado daconsulta de entrada. O método é capaz de identificar os bancos de dados envolvidos naconsulta 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étodopermite 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 dedados NOSQL.

A comunicação com os bancos de dados acessíveis pelo método é realizada pormeio da API JDBC, ou seja, é criado um mecanismo único de acesso aos dados, emque é 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 pelomé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ênciade tarefas abaixo:

1. Identificar a operação.2. Identificar as relações.3. Identificar os atributos.4. Identificar os predicados.5. Construir consultas SQL específicas para cada banco de dados.6. Identificar os metadados para comunicação com os bancos de dados.7. Executar as consultas construídas nos respectivos bancos de dados.8. Receber os resultados parciais das consultas executadas nos vários bancos de dados.9. Realizar a integração dos dados.

10. Apresentar o resultado da consulta.

4.2 Estrutura do método

O diagrama de fluxo de dados do método proposto é apresentado na Figura4.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, ofluxo do método se desenvolve através de quatro fases: Analisar Consulta SQL, ConstruirComandos SQL, Controlar Execução de Consultas SQL e Gerenciar Resultados. Osdepósitos de dados - Elementos SQL, Metadados, Fontes de Dados e Resultados -executam tarefas de armazenamento de configurações de conexão, consultas e resultadosparciais e final.

4.2.1 Consulta SQL Inicial

A consulta inicial é o ponto de entrada para a execução do método proposto. Asintaxe padrão da linguagem de consulta SQL é utilizada para compor uma consulta eas relações e atributos que podem ser utilizados são descritos no depósito Metadados. A


Figura 4.1: Fluxo de dados do método proposto

consulta SQL inicial é construída com base no esquema local, ou seja, nos metadados dearmazenamento configurados.

A Figura 4.2 ilustra um exemplo de consulta SQL de entrada. Caso a consultacontenha atributos de relações diferentes com nomes iguais, é necessário preceder o nomedo atributo com o nome da relação. Todos os demais componentes da consulta seguema sintaxe padrão SQL. É importante notar que nenhuma referência é feita aos bancos dedados relevantes para a consulta, os quais serão identificados posteriormente através dasrelaçõ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 relacionale 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 paraarmazenar temporariamente os seguintes dados: a consulta SQL inicial, os elementos SQLextraídos da consulta SQL inicial, as novas consultas SQL construídas para cada relação


da consulta SQL inicial, os resultados parciais obtidos da execução das novas consultasSQL construídas.

Elementos SQL

No processo de identificação de elementos SQL a partir da consulta inicial, cadaelemento identificado é armazenado temporariamente para ser consumido pelo processode construção de comandos SQL. Os elementos da consulta SQL inicial armazenadosneste depósito de dados são: o tipo da operação, a lista de relações referenciadas, a listade atributos de cada relação e os predicados específicos de cada relação (um predicadoespecífico inclui atributos de uma única relação). As consultas construídas para cadarelaçã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çõesque compoe o depósito Elementos SQL, bem como a estrutura das relações. O diagramamostra que uma relação pode conter vários atributos, e que uma relação pode conter váriospredicados (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 espe-

cificar o próximo predicado (and, or, in) e o nome da relação que mantém o atributoreferenciado no predicado.


A Figura 4.4 representa outras duas classes que compoe o depósito ElementosSQL. As relações não possuem relacionamento entre si, pois mantém temporariamente, narelaçã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, juntamentecom o nome da relação.

Os dados armazenados temporariamente nas relações deste depósito de dadossã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 quesão mantidas informações necessárias para conexão com os bancos de dados acessíveispelo método, bem como suas respectivas estruturas de armazenamento (relações e atribu-tos).

A Figura 4.5 apresenta o diagrama de classe que representa as relações quecompõe os metadados de conexão dos bancos de dados utilizados pelo método. Odiagrama mostra que um banco de dados está associado a um único domínio e um domíniopode conter vários bancos de dados. Um banco de dados pode conter várias relações e umarelação pode conter vários atributos. A classe Dominio representa o domínio (assunto dosdados) que são acessíveis pelo método.

Os metadados de conexão devem ser configurados manualmente e são repre-sentados 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.


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ãorepresentados, na Figura 4.5, pelas relações Relacoes e Atributos, e incluem, para cadarelaçã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 derelações. Por esta restrição, bancos de dados no mesmo domínio não podem ter relaçõescom 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


dados de diferentes categorias; a consulta SQL inicial não faz referência direta aos bancosde dados, mas utiliza os nomes de relações para identificar os bancos de dados relevantespara uma consulta.

Para viabilizar uma consulta a bancos de dados de diferentes categorias, nocontexto do mecanismo proposto neste trabalho, a estrutura de um banco de dadosNOSQL deve ser descrita na forma de relações e atributos.

• Mapeamento de um banco de dados orientado a colunas para relacionalO mapeamento de um banco de dados orientado a colunas para relacional deveser feito manualmente, no qual o keyspace é representado pelo nome do banco dedados, uma família de colunas é representada pelo nome da relação, a chave dacoluna é representada por um atributo [1]. A Figura 4.6 exemplifica a estruturade um banco de dados orientado a colunas mapeado para a estrutura relacional.O exemplo ilustra um keyspace denominado Estoque, contendo uma família decolunas chamada Clientes, em que cada coluna da família de colunas correspondea um atributo de cliente e sua representação relacional.

Figura 4.6: Estrutura de um banco de dados orientado a colunasmapeada para o modelo relacional

• Mapeamento de um banco de dados orientado a documentos para relacionalDe modo análogo, o mapeamento de um banco de dados orientado a documentospara uma estrutura relacional é feito de forma manual e deve ter a seguintecorrespondência: o banco de dados receberá o nome do banco de dados criado paraarmazenar a coleção de documentos, uma coleção de documentos é representadapelo nome da relação, um documento é representado por uma tupla, um atributocontido no documento é represento por um atributo da relação.A Figura 4.7 exemplifica o mapeamento da estrutura de um banco de dadosorientado a documentos para a estrutura relacional. A esquerda ilustra uma coleçãode documentos chamada Clientes, na qual cada documento corresponde ao registrode um cliente, e à direita, a estrutura relacional correspondente.


Figura 4.7: Estrutura de um banco de dados orientado a documen-tos mapeada para o modelo relacional

Fontes de Dados

O depósito Fontes de Dados representa o conjunto de bancos de dados que podemser 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 deconexão e descrição do armazenamento.

Para os metadados de conexão, são mantidas informações que possibilitamconectar aos bancos de dados, tais como: nome do banco de dados, usuário, senha, portade comunicação e uma indicação do driver JDBC do banco de dados. Para os metadadosque descrevem armazenamento, são mantidas informações, tais como: nome de cadarelaçã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 dadosconsideradas.

Resultados

O depósito Resultados armazena os resultados gerados por cada banco de dadosenvolvido na consulta. Para cada relação da consulta, é criada uma relação temporária nobanco de dados local com o mesmo nome e os mesmos atributos da relação da consultaSQL inicial. A integração dos dados e o retorno do resultado final da consulta são geradosa partir deste depósito de dados.

Assim como no depósito Elementos SQL, os dados armazenados e as relaçõescriadas temporariamente neste depósito de dados são excluídos após serem executadastodas as fases do método.

4.2.3 Analisar Consulta SQL

A função Analisar Consulta SQL corresponde ao procedimento de segmentaçãoda consulta SQL inicial, para identificar, separadamente, os componentes das cláusulas


select, from e where. Cada elemento identificado é armazenado no depósito ElementosSQL. As tarefas identificar operação, identificar as relações, identificar os atributos eidentificar 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 nodepósito Elementos SQL: o tipo da operação, as relações da consulta, e, para cadarelaçã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 nacláusula where que não podem ser executados pelos gerenciadores de bancos de dadosNOSQL, tais como: sum, min, max, avg, count, group by, having, between. Assim, aprimeira tarefa executada na fase de análise da consulta SQL inicial consiste em eliminaros elementos citados, caso existam. Nesta fase, os elementos citados são eliminadosda 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ãoidentificados 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 daprimeira tarefa na fase de análise da consulta SQL inicial, foram eliminados os atributosque indicam relacionamentos, pois esses atributos e o relacionamento pode não existirno 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 decada relação e os predicados específicos de cada relação.

• Operação: a palavra indicativa da operação realizada é identificada e armazenadano 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 opar relação e atributo. Caso contrário, é necessária uma consulta no depósito Meta-dados 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émo atributo referenciado no predicado. Por exemplo: se o atributo é precedido do


nome da relação, é identificado o predicado e a relação. Caso contrário, é feita umaconsulta no depósito Metadados para identificar a relação que contém o atributo.Cada par <predicado,relação> identificado é armazenado no depósito ElementosSQL

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 mantidostemporariamente no depósito Elementos SQL. Os elementos identificados são os mesmosexemplificados na Figura 4.8.

O algoritmo 1 apresenta os passos que são executados para segmentar a consultaSQL inicial e identificar cada elemento SQL separadamente.

4.2.4 Construir Comandos SQL

Esta etapa é responsável por construir consultas SQL, uma consulta para cadarelação identificada na consulta SQL inicial. Para tanto, utiliza os elementos da consultainicial armazenados no depósito Elementos SQL.

Na consulta SQL de entrada, é necessário informar os atributos de relaciona-mentos, no caso, rel1.id = rel2.id, pois quando a consulta for executada nos respectivosbancos de dados e os resultados armazenados temporariamente no depósito Resultados, aconsulta 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áriasdo depósito Resultados.

O algoritmo 2 apresenta os passos que são executados para construir consultasSQL para cada relação envolvida na consulta inicial.


Algoritmo 1: Analisar a consulta SQL inicialEntrada: Consulta SQL inicialSaída: Operação, relações, atributos e predicados da consulta inicialinicio

Elimina ElementosElimina PredicadosIdentifica OperaçãoIdentifica RelaçõesIdentifica Atributose Atributo Indica Agregação então

Identifica Atributose Precede Relação então

Grava Par Atributo-Relaçãofimsenão

Identifica Relação do AtributoGrava Par Atributo-Relação

fimfimsenão

se Precede Relação entãoGrava Par Atributo-Relação

fimsenão

Identifica Relação do AtributoGrava Par Atributo-Relação

fimfimse Existe Predicado então

se Relacao Precede Atributo entãoGrava Predicado

fimsenão

Identifica Relação do AtributoGrava Predicado

fimfim

fin

As consultas SQL construídas nesta fase são armazenadas no depósito ElementosSQL, cada uma com uma referência ao banco de dados objeto da consulta. A Figura4.10 exemplifica as consultas SQL construídas pelo método a partir da consulta inicialexemplificada na Figura 4.8. Neste exemplo, o banco de dados BD1 é ilustrado em umbanco de dados relacional e o banco de dados BD2 é ilustrado em um banco de dadosNOSQL.


Figura 4.10: Consultas construídas pelo método.

Algoritmo 2: Construir consultas SQLEntrada: Elementos SQL extraídos da consulta inicialSaída: Consultas SQL para cada relação da consulta inicialinicio

Busca Relações no Depósito Elementos SQLenquanto Existe Relação faça

Identifica Atributos da Relação AtualIdentifica Predicados da Relação AtualIdentifica Bd da Relação AtualConstrói Consulta SQLGrava Consulta SQL no Depósito Elementos SQL

fimfin

4.2.5 Controlar Execução de Consultas SQL

O processo Controlar Execução de Consultas SQL realiza toda a tarefa de enviodas consultas para os bancos de dados referenciados na consulta SQL inicial. Para cadaconsulta, são executadas as seguintes tarefas:

1. Criar relações temporárias no depósito Resultados.2. Buscar metadados de conexão com o banco de dados no depósito Metadados.3. Estabelecer a conexão com o banco de dados.4. Enviar a consulta para execução.5. Receber o resultado da consulta.6. 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 afim de receber os resultados obtidos em cada consulta executada. As relações são criadascontendo os atributos de cada relação informados na consulta SQL inicial.


As tarefas Estabelecer a conexão com o banco de dados, Enviar a consulta paraexecução e Receber o resultado da consulta são realizadas com o apoio do driver JDBCde cada banco de dados. Para os bancos de dados NOSQL, o próprio driver JDBC tem atarefa 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 consultasconstruídas para cada relação envolvida na consulta inicial e armazenar os resultadosparciais no depósito Resultados.

Algoritmo 3: Executar consultas SQL construídasEntrada: Comandos SQL construídos para cada relação da consulta inicialSaída: Resultados parciais obtidos em cada banco de dadosinicio

Busca Relações no Depósito Elementos SQLenquanto Existir Relação faça

Busca Comando SQL ConstruídoBusca Metadados da RelaçãoBusca Metadados de Conexão do Banco de Dadosse Categoria = Coluna então

Executa Consulta Banco de Dados ColunaGrava Resultado Parcial da Consulta no Depósito Resultados

fimse Categoria = Documento então

Executa Consulta Banco de Dados DocumentoGrava Resultado Parcial da Consulta no Depósito Resultados

fimse Categoria = Relacional então

Executa Consulta Banco de Dados RelacionalGrava Resultado Parcial da Consulta no Depósito Resultados

fimfim

fin

4.2.6 Gerenciar Resultados

Este processo executa a consulta SQL de entrada no depósito Resultados utili-zando os resultados parciais armazenados. Este processo é exemplificado na Figura 4.11.

A solução adotada permite executar a consulta SQL inicial em um banco dedados relacional, mesmo que os resultados parciais tenham sido obtidos de bancos dedados NOSQL. Assim, com os resultados parciais mantidos em um banco de dadosrelacional, é possível utilizar todos os recursos que a linguagem SQL oferece, tais como


junções, agregações, ordenações e outros recursos não disponíveis em bancos de dadosNOSQL.

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 Ven-

das.IdCliente = Cliente.IdCliente and DataVenda = 22/05/2013 and Nome = Pedro, emque a relação Vendas está armazenada em um banco de dados NOSQL orientado a colu-nas e a relação Cliente está armazenada em um banco de dados relacional, os passos quesão executados para obter o resultado final são:

• Passo 1:Objetivo: eliminar os elementos que não são reconhecidos pelo analisador Zql eatributos de relacionamentos.Resultado: select IdVenda, DataVenda, Vendas.IdCliente, Cliente.IdCliente, Total-

Venda, 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 iniciale 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 VendasAtributos IdVenda, IdCliente, DataVenda, TotalVendaPredicado 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


Relação ClienteAtributos IdCliente, Nome e EnderecoPredicado 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. Oresultado do passo 3 é ilustrado na Tabela 4.3.

Consulta 1 select IdVenda, IdCliente, DataVenda, TotalVenda from Vendaswhere DataVenda = 22/05/2013

Consulta 2 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 parci-ais temporariamente.Resultado: relações Cliente e Vendas criadas temporariamente no depósito Resul-tados. O resultado é ilustrado nas tabelas 4.4 e 4.5.

Relação ClienteIdCliente Nome Endereco

2 Pedro Rua 12, n54

Tabela 4.4: Relação Cliente criada no depósito Resultados.

Relação VendasIdVenda 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.


Resultado da consulta inicialIdVenda 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ósitoResultados.

• Passo 6:Objetivo: eliminar todas as relações temporarias criadas no passo 4 e todos os ele-mentos SQL identificados no passo 2.Resultado: relações criadas no passo 4 excluídas do depósito Resultados. Elemen-tos SQL identificados no passo 2 eliminados do depósito Elementos SQL.

Os passos apresentados anteriormente aplicam todos os processos descritos dométodo proposto. É importante destacar que, na consulta SQL inicial, alguns atributos fo-ram solicitados precedendo o nome da relação, pois existem, na mesma consulta, atributoscom o mesmo nome. Portanto, é necessário informar qual relação mantém o respectivoatributo. Entretanto, outros atributos não foram precedidos pelo nome da relação. Nestecaso, o método é capaz de identificar através dos metadados de armazenamento a relaçãoque mantém um determinado atributo.

A partir da apresentação do método proposto, é possível definir como principalcontribuição deste trabalho, acessar vários bancos de dados através de uma única consultaescrita 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 executarconsultas 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 estejamarmazenados em bancos de dados NOSQL.

CAPÍTULO 5Um protótipo para avaliar o método deintegração de dados

Para demonstrar a viabilidade do método proposto neste trabalho, um protótipofoi desenvolvido. Nesta seção estão descritas sua estrutura, seus requisitos funcionais enão funcionais, os desafios encontrados durante o seu desenvolvimento, as configuraçõesrealizadas para permitir o funcionamento do protótipo e os resultados obtidos com aexecução do protótipo.

Diante do contexto apresentado no Capítulo 1, dos trabalhos relacionados aoassunto de integração de dados no Capítulo 2 e do método apresentado no Capítulo 4, osobjetivos do protótipo são:

• Permitir a experimentação do método proposto através de consultas escritas nopadrão da linguagem de consulta SQL, contendo elementos que não são executadosde 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, entreeles, estão:

• Cada categoria de bancos de dados NOSQL oferece recursos diferentes na manipu-lação de dados, além de serem diferentes da abordagem relacional, motivos pelosquais 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 paraaplicar o método proposto.

• Encontrar um driver JDBC para cada banco de dados NOSQL.

5.2 Requisitos do protótipo 54

5.2 Requisitos do protótipo

Os requisitos funcionais são as especificações do que o sistema deve fornecer, decomo 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 linguagemSQL e um mecanismo de visualização do resultado final da consulta. Após o término daconsulta, o protótipo deve estar preparado para uma nova consulta. Além disso, devepermitir as configurações de metadados necessários para executar uma consulta, taiscomo: 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 doprotótipo.

Requisito DescriçãoRF1 Os metadados de conexão dos bancos de dados disponíveis devem

ser configurados.RF2 Devem ser configurados os metadados de armazenamento, tais

como: relações, atributos, predicados e domínios.RF3 Deve haver meios de se inserir uma consulta no padrão da lingua-

gem SQL.RF4 O protótipo deve acessar os bancos de dados envolvidos na con-

sulta SQL inicial, e, para isso, utilizar os metadados de conexãopreviamente configurados.

RF5 O protótipo deve construir novas consultas SQL, uma para cadarelação identificada na consulta SQL inicial.

RF6 As novas consultas devem ser executadas em seus respectivosbancos de dados.

RF7 Os resultados parciais gerados em cada banco de dados devem serintegrados 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 pelosistema [36]. Por exemplo: se um sistema funciona em rede ou não, quais bancos dedados utilizados, tempo máximo de consulta e etc. A tabela 5.2 apresenta os requisitosnão funcionais do protótipo.

Requisito DescriçãoRNF1 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 55

5.3 Descrição do protótipo

Nesta seção são descritas as tecnologias utilizadas no desenvolvimento do pro-tó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 desenvolvi-mento, 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 insta-lado em computadores distribuídos em uma rede, não sendo necessário a utilização debrowsers 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 funciona-lidades para cadastramento de metadados.

• Cadastrar BD: opção disponível para configurar os bancos de dados acessíveis noprotótipo, bem como seus metadados de conexão.

• Cadastrar Relações: opção disponível para configurar as relações que compõe umbancos de dados.

• Cadastrar Atributos: opção disponível para configurar os atributos de cada rela-ção.


• 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 bancosde 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 posteriormenteprecedida 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 adocumentos, 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.


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 emcomum:

• 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 caracte-rísticas desejadas para esse trabalho, ou seja, com dados distribuídos em bancos de dadosrelacionais e NOSQL, foi necessário criar alguns bancos de dados de exemplo para apli-car o método proposto. Os bancos de dados apresentados nesta seção são considerados depequeno porte e utilizados apenas para o experimento, motivo pelo qual, aspectos comoescalabilidade, desempenho e tempo de consulta não foram considerados nos experimen-tos. Por este motivo, o objetivo dos experimentos é validar o método proposto executandoconsultas escritas no padrão da linguagem de consulta SQL em bancos de dados relaci-onais e NOSQL, contendo elementos não executados de forma nativa pelos bancos dedados NOSQL.

Como explicado no Capítulo 3, bancos de dados NOSQL não permitem rela-cionamentos. Entretanto, para ilustrar o domínio e as famílias de colunas, coleções de


documentos e relações criadas para executar os experimentos, foram criados diagramasde classe, e em alguns diagramas, contendo a indicação de relacionamentos, porém, essesrelacionamentos são realizados na aplicação.

5.4.1 Ambiente dos experimentos

O protótipo implementado é composto por elementos que precisam ser confi-gurados para alcançar os objetivos propostos pelo método. A seguir são apresentadas asconfiguraçõ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 Categoria Domínio Servidor Porta JDBC Usuario SenhaBDVendas Coluna Varejista localhost 9160 jdbc:

cassan-dra

CondPag Documento Varejista localhost 27017 jdbc:mongo

BDDados Relacional Varejista FLAVIOFAV 1433 jdbc:sqlser-ver

FAV 123

Clientes Documento Varejista localhost 27017 jdbc:mongo

BDFuncionarios Relacional Varejista localhost 5432 jdbc:post-gresql

postgres fav123

Fornecedor Documento Varejista localhost 27017 jdbc:mongo

Tabela 5.3: Configuração dos metadados de conexão no depósitoMetadados

A Tabela 5.3 apresenta a configuração dos metadados de conexão dos bancos dedados acessíveis pelo protótipo.

O domínio criado para aplicar o método proposto corresponde a uma empresafictícia de vendas e mantém informações sobre vendas efetuadas, tais como: número davenda, data da venda, nome do cliente, produtos vendidos e outros dados referentes àsvendas. As consultas podem solicitar, por exemplo, informações sobre as vendas efetuadasem um período de tempo, a média das vendas entre um mês e outro, as compras efetuadaspor 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 colunascriadas em bancos de dados relacionais e em bancos de dados NOSQL a fim de realizar osexperimentos. Foi criado um keyspace no banco de dados Cassandra chamado BDVendas,e nele foram criadas duas famílias de colunas, Vendas e ItensVenda. Foram criadostrês bancos de dados no banco de dados MongoDB: Fornecedor, e criada também uma


SGBD Categoria Nome Banco RepositóriosCassandra Coluna BDVendas Vendas, ItensVendaMongoDB Documento Fornecedor FornecedorMongoDB Documento Clientes ClientesMongoDB Documento CondPag CondPag

MSSQL Server Relacional BDDados Produto, EntradaNFe, ItensEntradaPostgresql Relacional BDFuncionarios 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 dedocumentos chamada Clientes; CondPag, e criada também uma coleção de documentoschamada CondPag. No banco de dados MSSQL Server foi criado um banco de dadoschamado BDDados com as seguintes relações: Produto, EntradaNFe e ItensEntrada. Nobanco de dados Postgresql foi criado um banco de dados chamado BDFuncionarios coma relação Funcionarios.

A Figura 5.6 apresenta o diagrama de classe que representa as famílias de colunascriadas no banco de dados Cassandra. O diagrama apresenta uma relação de composiçãoentre as relações Vendas e ItensVenda, na qual só haverá itens de venda se existir umavenda 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 Cas-sandra.

Os objetivos da família de colunas Vendas são armazenar informações sobre asvendas, 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:


• 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 dedados MongoDB.

A Figura 5.7 apresenta o diagrama de classe criado para representar a coleçãode documentos criada no banco de dados MongoDB chamada Clientes. A coleção dedocumentos Clientes é responsável por armazenar dados referentes aos clientes, taiscomo:

• 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 bancode dados MongoDB.

A Figura 5.8 apresenta o diagrama de classe criado para representar a coleçãode documentos criada no banco de dados MongoDB chamado Fornecedor. A coleção de


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 dedados MongoDB.

A Figura 5.9 apresenta o diagrama de classe criado para representar a coleçãode documentos criada no banco de dados MongoDB chamada CondPag. A coleção dedocumentos CondPag é responsável por armazenar dados referentes às condições depagamento disponíveis, tais como:

• O número que identifica a condição de pagamento, representado pelo atributoIdCondPag.

• 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çõescriadas no banco de dados MSSQL Server. O diagrama apresenta um relacionamentode composição entre as relações EntradaNFe e ItensEntrada, em que só haverá itensde entrada se houver uma entrada relacionada aos itens, e uma relação de agregaçãoentre as relações ItensEntrada e Produto, em que cada item da entrada tem um produtorelacionado, e poderá haver produtos cadastrados mesmo se não houver entradas.

A relação EntradaNFe é responsável por armazenar as informações principaisdas 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 DataEn-

trada.


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 produtosdisponí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çãocriada no banco de dados Postgresql. O diagrama apresenta a classe Funcionarios, na qualarmazena informações sobre os funcionários (vendedores, atendentes e etc.), tais como:


Figura 5.11: Relação Funcionarios criada no banco de dadosPostgresql.

• 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, foicriado um diagrama de classe contendo todas as relações, famílias de colunas e coleçõesde documentos utilizadas no domínio. A Figura 5.12 apresenta o diagrama de classe e aseguinte estrutura:

Figura 5.12: Relações utilizadas no experimento

• A família de colunas Vendas se relaciona:


– 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 relacionaisMSSQL Server 2008 Express e Postgresql 9.3, e os bancos de dados NOSQL Cassandra2.1.2, da categoria orientado a colunas, e MongoDB 2.4.5, da categoria orientado a do-cumentos. 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 dadosque 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 2008Express.

A escolha pelo banco de dados MSSQL Server e Postgresql da categoria relaci-onal se justifica pelo amplo material de apoio aos desenvolvedores, por ser um banco dedados utilizado por grande parte das aplicações existentes, e, por ser classificado como re-lacional, oferece todos os recursos que a abordagem proporciona. A opção pelo Cassandracomo banco de dados NOSQL orientado a colunas se justifica por ser o banco de dadosda categoria NOSQL que mais se assemelha à abordagem relacional. O banco de dadosMongoDB foi escolhido devido a sua particularidade em armazenar os dados no formatode documentos, e, por esse motivo, é um desafio encontrar um mecanismo que permita aintegração das três abordagens, relacional, orientado a colunas e orientado a documentosna mesma aplicação. Uma justificativa que se aplica a todos os bancos de dados é queambos 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 avaliardiferentes 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 dadosutilizados nos experimentos, nas seguintes combinações:


• 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 secomunica com os bancos de dados MSSQL Server, Postgresql, Cassandra e MongoDB.Esse ambiente pode representar uma empresa do ramo varejista, acadêmico, industrial eoutros 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 conside-rando as várias formas de se construir uma consulta SQL. Foram construídas consultasSQL envolvendo os quatro bancos de dados utilizados nos experimentos, mas não neces-sariamente utilizados ao mesmo tempo em todas as consultas. A cada exemplo apresen-tado, são informados quais bancos de dados foram utilizados.


Consultas envolvendo apenas bancos de dados relacionais

Consulta 1: exemplo de consulta que acessa apenas um banco de dados relacio-nal.

• Objetivo da consulta: apresentar todas as entradas de notas fiscais entre os dias01/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 oresultado 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.


• Objetivo da consulta: apresentar todas as entradas de notas fiscais entre os dias01/01/2015 e 01/05/2015 e mostrar o funcionário que efetuou a venda, bem comoo 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.




Consultas envolvendo apenas bancos de dados NOSQL

Sabe-se que os bancos de dados NOSQL não oferecem a utilização de deter-minados operadores, tais como: join, between group by, avg, min, max, sum e outros


operadores. Entretanto, para demonstrar que a partir do método proposto é possível via-bilizar essa necessidade, nesta seção serão apresentadas várias consultas SQL contendoelementos 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 dias01/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óriode campos númericos, group by para agrupamento e order by para ordenação.






• Objetivo da consulta: apresentar a quantidade das vendas efetuadas, agrupadas pordata 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 filtrarpelo resultado do campo agrupado e order by para ordenação.




Consulta 5: exemplo de consulta que acessa apenas um banco de dados NOSQL.


• Objetivo da consulta: apresentar a média do valor total de vendas, agrupadas pordata 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.





• Objetivo da consulta: apresentar o valor mínimo, agrupado por data da venda, dosprodutos vendidos para a cliente Larissa de Assis Vilela entre os dias 01/03/2015 e01/08/2015.


• 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 eorder by para ordenação.





• 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 AssisVilela, a partir do dia 01/05/2015.


• 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 agrupamentoe order by para ordenação.





• 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 clientescujo o nome comece com a letra L.


• 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 textosaproximados, group by para agrupamento e order by para ordenação.




Consultas envolvendo bancos de dados relacionais e bancos de dados NOSQL

Consulta 9: exemplo de consulta que acessa um banco de dados relacional e umbanco de dados NOSQL.


• 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.




Consulta 10: exemplo de consulta que acessa dois bancos de dados relacionaise um banco de dados NOSQL.

• Objetivo da consulta: apresentar a somatória da quantidade de produtos vendidospor funcionário das vendas efetuadas entre os dias 01/03/2015 e 01/07/2015, em


que contenha, entre a descrição do produto, a expressão "de", e exibir somente osresultados 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 paraagrupamento, order by para ordenação e having para filtrar a partir da cláusulagroup by.




Consulta 11: exemplo de consulta que acessa dois bancos de dados relacionaise dois bancos de dados NOSQL.


• Objetivo da consulta: apresentar as vendas efetuadas entre os dias 15/05/2015 e01/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.




Após a execução dos experimentos, alguns aspectos referentes as consultas deentrada e os resultados produzidos devem ser considerados:


• Algumas consultas foram escritas precedendo o atributo com o nome da relaçãoao qual pertence. Essa restrição é válida se na consulta de entrada ou no mesmodomí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 sejacomposta pelo atributo correto.

• Em consultas contendo intervalo entre datas, foram utilizados os operadoresbetween e >= e <=. Essa situação foi apresentada apenas para mostrar que exis-tem as duas maneiras de especificar um intervalo de datas, mesmo se o atributoestiver 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 atributosque 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 é criadocom base nas novas consultas SQL criadas para cada relação envolvida na consultade entrada e nos atributos de cada relação solicitados na consulta, como já foiexplicado anteriormente. Portanto, no depósito de Resultados devem conter todosos atributos solicitados na consulta de entrada, inclusive os atributos que indicamrelacionamentos.

Os resultados obtidos mostram que o acesso aos bancos de dados relacionaise NOSQL através de uma única consulta foi possível através do driver JDBC de cadabanco de dados. Ao receber a consulta no padrão SQL, o driver JDBC faz o mapeamentodos elementos SQL para cada banco de dados, relacional ou NOSQL. Portanto, para aviabilidade do método, é indispensável a utilização do driver JDBC de cada banco dedados acessível pelo método.

A partir da utilização do protótipo e dos resultados obtidos, foi possível analisarque a configuração dos metadados de conexão e armazenamento deve ser realizada porpessoas que conhecem o domínio sobre o qual as consultas serão executadas. Isso se deveao fato de que, na abordagem adotada neste trabalho, os metadados são configuradosmanualmente, 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 aplicaro método proposto. Foram discutidas todas as configurações realizadas para acessaros bancos de dados envolvidos na consulta, bem como as configuração das relações eatributos dos bancos de dados acessíveis pelo protótipo. A partir da implementação doprotótipo, foi possível validar o método proposto neste trabalho e verificar que é possível


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. Nopróximo capítulo serão discutidas as conclusões e trabalhos futuros.

CAPÍTULO 6Conclusão

Este trabalho propõe um método de integração de dados armazenados em bancosde dados de diferentes abordagens. O método permite o acesso a dados armazenadosem 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 pordeterminadas 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, como propósito de padronizar a forma de acesso às fontes de dados disponíveis adotou a APIJDBC. 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çõesrelevantes para a consulta. Os resultados obtidos pelas consultas específicas são armaze-nados temporariamente em um banco de dados relacional, o que torna possível submetera consulta inicial e obter o resultado final, composto por dados previamente recuperadosde vários bancos de dados.

Este trabalho foi inspirado em [45], no qual é proposto um método de integraçãode dados entre bancos de dados relacionais e NOSQL. Entretanto, o método propostoneste trabalho permite a utilização da linguagem de consulta SQL como meio padrão deconsulta dos dados. Como consequência, é permitida a utilização de elementos SQL, taiscomo sum, count, join e outros elementos, mesmo que os dados estejam armazenados embancos de dados NOSQL.

As próximas seções apresentam as contribuições, os trabalhos futuros e ostrabalhos produzidos durante o desenvolvimento desta dissertação.

6.1 Contribuições 81

6.1 Contribuições

Nesta seção são apresentadas as principais contribuições com o desenvolvimentodeste trabalho.

• Permitir acessar fontes de dados de diferentes abordagens através de uma única

consulta SQL: os dados solicitados em uma consulta podem estar armazenadosem diferentes fontes de dados, porém, uma consulta SQL de entrada contendo asrelaçõ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 bancosde 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 deidentificar, através de metadados previamente configurados, as relações, atributose 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 aosdados, 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ãoconsultados através de uma única consulta, e os resultados produzidos em cadabanco de dados são apresentados de forma unificada.

6.2 Trabalhos Futuros

Durante o desenvolvimento do trabalho foram identificados vários aspectos quepodem contribuir para o aprimoramento do método proposto. Dentre eles, estão:

• Permitir consultas não necessariamente no padrão SQL: para executar consultasutilizando o método proposto, é necessário informar uma consulta no padrão SQL erespeitar rigorosamente a sintaxe SQL. Uma alternativa seria disponibilizar outrasformas 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étodoproposto reconhece apenas os bancos de dados relacionais e NOSQL. A integraçãode 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 catego-

rias 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 do-cumentos. Entretanto, é importante realizar a integração entre outras categorias debancos de dados NOSQL, tais como: orientado a grafos, chave-valor, bancos dedados 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 desenvolvimentonão foi possível encontrar um ambiente real para executar os experimentos. Emum ambiente real contendo bancos de dados relacionais e NOSQL, seria possívelavaliar melhor o método proposto.

• Permitir a execução de operações inserção, alteração e exclusão de dados: estetrabalho foi desenvolvido considerando apenas a operação de consulta. Permitiroutras operações SQL significa construir um método completo que contemple todasas operações.

• Permitir utilizar outros elementos SQL não contemplados neste trabalho: o métodoproposto neste trabalho permite realizar consultas contendo elementos SQL nãoreconhecidos 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 quesão aceitos neste trabalho. Permitir executar consultas contendo, por exemplo:subconsultas, inserção de dados através de consultas e até mesmo contemplaras especificidades de cada banco de dados é importante para o método executarquaisquer elementos da linguagem SQL.

APÊNDICE ADados para executar os experimentos

As tabelas a seguir apresentam os dados utilizados para realizar os experimentos.

Coleção de documentos ClientesIdClienteC Nome Endereco Cidade Telefone

1 Flavio Vilela Rua Voluntariosda Patria, 353

Jatai 6436311873

2 Jose Caetano de Assis Rua Miguel deAssis, 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

5 Joaquim Caetano de Assis Avenida Volunta-rios da Patria, 121

Jatai 6436361254

6 Junior dos Santos Avenida Goias,222

Goiania 6432546321

7 Larissa de Assis Vilela Avenida Presi-dente Vargas,562

Acreuna 6436456321

8 Lorena de Assis Vilela Rua da saudade,221

Jatai 6436312102

Tabela A.1: Dados armazenados na coleção de documentos Clien-tes

APÊNDICE A. DADOS PARA EXECUTAR OS EXPERIMENTOS 84

Coleção de documentos CondPagIdCondPag DescricaoCP

1 Dinheiro

2 Cartao

3 Cheque

4 Promissoria

Tabela A.2: Dados armazenados na coleção de documentos Cond-Pag

Coleção de documentos FornecedorIdFornecedor RazaoSocial CNPJ Endereco Cidade

1 JR Distribuidora 123456-1 Rua X, 223 Jatai-GO

2 Vilela ImplementosAgricolas

456123-2 Rua Y, 2301 Jatai-GO

3 MKT Pecas e Aces-sorios

854565-1 Rua Z, 32 Jatai-GO

4 Coringa das RodasLTDA

201202-1 Rua K, 1200 Jatai-GO

5 FAV Molas e Parafu-sos

784452-8 Rua W, 56 Jatai-GO

6 Junior Auto Pecas eDistribuidora LTDA

552211-8 Rua A, 1256 Goiania-GO

7 Comando PecasAgricolas

200112-3 Rua C, 556 Goiania-GO

8 Reg Implementos ePecas


9 Distribuidora LopesLTDA


10 Trovao Pecas e Im-plementos

452123-9 Rua B, 6633 Goiania-GO

Tabela A.3: Dados armazenados na coleção de documentos For-necedor


Família de colunas VendasIdVenda 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 ItensVendasIdVenda IdProduto PrecoUnitario Quantidade SubTotal

1 1 10 2 20


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


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


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


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 ItensVen-das

Relação ProdutoIdProduto DescricaoProduto Codigo PrecoUnitario Estoque

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

8 Celular Black Barry 28282811 550 8

9 Celular Nexus 5 22828919 600 9

10 Mouse Lazer 399322 25 2

Tabela A.6: Dados armazenados na relação Produto


Relação FuncionariosIdFuncionario 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 EntradaNFeIdEntrada 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 ItensEntradaIdEntrada IdProduto ValorCompra Quantidade SubTotal

1 1 10 2 20


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


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


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] ABRAMOVA, V.; BERNARDINO, 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] BARBULESCU, M.; GRIGORIU, R.-O.; HALCU, I.; NECULOIU, G.; SANDULESCU, VIR-

GINIA, C.; MARINESCU, M.; MARINESCU, V. Integrating of structured, semi-

structured and unstructured data in natural and build environmental engine-

ering. Roedunet International Conference (RoEduNet), 2013 11th, 1:1–4, 2013.

[3] BLUMBERG, R.; ATRE, S. The Problem with Unstructured Data. DM Review, 2003.

[4] CALIL, A.; DOS SANTOS, MELLO, R. Simplesql: A relational layer for simpledb.

ADBIS’12 Proceedings of the 16th East European conference on Advances in Data-

bases and Information Systems, 1:99–110, 2012.

[5] CASSANDRA. Cassandra jdbc driver, 12 2014. Disponível em:

https://code.google.com/a/apache-extras.org/p/cassandra-jdbc/. Acesso em: 5

dez. 2014.

[6] CASSANDRA, A. Cassandra query language (cql). Disponível em:

https://cassandra.apache.org/doc/cql3/CQL.html. Acesso em: 4 set. 2014.

[7] CASSANDRA, 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] CATTELL, R. Scalable sql and nosql data stores. ACM SIGMOD Record, 39(4):12–

27, Dezembro 2010.

[9] CHUNG, W.-C.; LIN, H.-P.; CHEN, S.-C.; JIANG, M.-F.; CHUNG, Y.-C. Jackhare:

a framework for sql to nosql translation using mapreduce. Automated Software

Engineering, 21:489–508, 2013.

[10] DOS SANTOS, FERREIRA, G.; CALIL, A.; DOS SANTOS, MELLO, 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] DUGGAN, J.; ELMORE, AARON, J.; STONEBRAKER, M.; BALAZINSKA, M.; HOWE, B.

The bigdawg polystore system. SIGMOD Record, 44:11–16, 2015.

[12] GEETHA, S.; MALA, D. G. S. A. Effectual extraction of data relations from

unstructured data. Third International Conference on Sustainable Energy and

Intelligent System, 1:1–4, 2012.

[13] HAN, J.; E, H.; LE, G.; DU, J. Survey on nosql database. In Proceedings of 6th

International Conference on Pervasive Computing and Applications (ICPCA 2011),

1:363–366, Outubro 2011.

[14] HECHT, R.; JABLONSKI, S. Nosql evaluation - a use case oriented survey. 2011

International Conference on Cloud and Service Computing, 1:336–341, Dezembro

2011.

[15] JATANA, N.; PURI, S.; AHUJA, M.; KATHURIA, I.; GOSAIN, 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.; RITTER, N.; REIMER, O. Towards integrated query processing for

object-relational and xml data sources. 10th International Database Engineering

and Applications Symposium, 1:1, 2006.

[17] LAWRENCE, 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] LEAVITT, N. Will nosql databases live up to their promise? In IEEE Computer,

43(2):12–14, 2010.

[19] LI, Y.; MANOHARAN, 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] MCGREAL, R. Learning objects and metadata understanding the field. Internati-

onal Workshop on Technology for Education (T4E), 1:49 – 53, 2009.

[21] MOHAMED, MOHAMED, A.; ALTRAFI, OBAY, G.; ISMAIL, MOHAMMED, O. Relational

vs. nosql databases: A survey. International Journal of Computer and Information

Technology (ISSN: 2279 – 0764), 3(3):598–601, 2014.


[22] MONGODB. Introduction to mongodb, 2 2015. Disponível em:

http://docs.mongodb.org/manual/reference/sql-comparison/. Acesso em: 5 fev.

2015.

[23] MONGODB, U. Jdbc driver for mongodb, 2014 12. Disponível em:

http://www.unityjdbc.com/mongojdbc/mongojdbc.php. Acesso em: 15 dez. 2014.

[24] MONIRUZZAMAN, A. B. M.; HOSSAIN, SYED, A. Nosql database - new era of da-

tabases for big data analytics - classification, characteristics and comparison.

International Journal of Database Theory and Application, 6:1–14, 2013.

[25] NANCE, C.; LOSSER, T.; IYPE, R.; HARMON, 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] NYATI, 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.; POE, S.; VRBSKY, S. V. Comparing nosql mongodb to an sql db.

Proceedings of the 51st ACM Southeast Conference, 5:1–6, 2013.

[29] POKORNY, J. Nosql databases: a step to database scalability in web environ-

ment. 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 Organiza-

tion, 2004.

[31] RAMAKRISHNAN, R.; GEHRKE, J. Database Management System. McGraw-Hili,

2003.

[32] ROUT, T.; GARANAYAK, M.; SENAPATI, MANAS, R.; KAMILLA, SUSHANTA, K. Big data

and its applications: A review. International Conference on Electrical, Electronics,

Signals, Communication and Optimization (EESCO) - 2015, 1:1–5, 2015.

[33] SCHRAM, A. Mysql to nosql data modeling challenges in supporting scalability.

Proceedings of the 3rd annual conference on Systems, programming, and applicati-

ons: software for humanity, 1:191–202, 2012.


[34] SILVA, JOÃO, C.; KOWATA, E. T.; VINCENZI, 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] SMULLEN, CLINTON, W.; TARAPORE, SHAHRUKH, R.; GURUMURTHI, S. A bench-

mark suite for unstructured data processing. Fourth International Workshop on

Storage Network Architecture and Parallel I/Os, 1:79 – 83, 2008.

[36] SOMMERVILLE, I. Engenharia de Software. Pearson, 2011.

[37] STONEBRAKER, M.; MADDEN, S.; ABADI, DANIEL, J.; HARIZOPOULOS, S.; HACHEM,

N.; HELLAND, 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] SU, J.; FAN, R.; LI, 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, CLARENCE, J. M.; ARAVINDH, 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] TUDORICA, BOGDAN, G.; BUCUR, C. A comparison between several nosql data-

bases with comments and notes. Roedunet International Conference (RoEduNet),

2011 10th, 5:1 – 5, 2011.

[41] VANGIPURAM, R. K.; SREEKANTH, V.; RANGASWAMY, B. Implementation of web-etl

transformation with pre-configured multi-source system connection and trans-

formation 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] WEI-PING, Z.; MING-XIN, L.; HUAN, 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] WILEY, J. Practical Database Programming with Java Chapter 3 - JDBC API and

JDBC Drivers. Ying Bai, 1 edition, 2011.


[45] ZHANG, H.; WANG, Y.; HAN, 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] ZHANG, H.; ZHANG, L.-Y. Jdbc-based middleware applications in instant mes-

sage systems. 2nd International Conference on Systems and Informatics (ICSAI

2014), 1:1044 – 1049, 2014.

um método de integração de dados armazenados em bancos de …¡vio... · 4.6 estrutura de um...

Documents