Middleware Clusters SGBDs

U IVERSIDADE ESTADUAL DO CEARÁ – UECE
Centro de Ciências Tecnológicas - CCT
I STITUTO FEDERAL DE EDUCAÇÃO, CIÊ CIA
E TEC OLOGIA DO CEARÁ - IFCE
Diretoria de Ensino – DIRE
MESTRADO PROFISSIO AL EM COMPUTAÇÃO APLICADA – MPCOMP
CICERO TADEU PEREIRA LIMA FRA ÇA
Um Middleware para o Gerenciamento de Clusters
de SGBDs Heterogêneos
FORTALEZA – CEARÁ
Setembro de 2010

CICERO TADEU PEREIRA LIMA FRA ÇA
Um Middleware para o Gerenciamento de Clusters
de SGBDs Heterogêneos
Dissertação apresentada ao Curso de Mestrado
Profissional em Computação Aplicada da Universidade
Estadual do Ceará e Instituto Federal de Educação,
Ciência e Tecnologia do Ceará como requisito parcial
necessário para obtenção do grau de Mestre em
Computação Aplicada, área de concentração: Redes de
Computadores
Orientador: Prof. Dr. Cidcley Teixeira de Souza
FORTALEZA – CE
Setembro de 2010

F814m França, Cicero Tadeu Pereira Lima
Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos / Cícero Tadeu Pereira Lima França - Fortaleza,
2010.
114 p.
Orientador: Prof. Dr. Cidcley Teixeira de Souza
Dissertação do Curso de Mestrado Profissional em
Computação Aplicada (MPCOMP) - Universidade Estadual do
Ceará e Instituto Federal de Educação, Ciência e Tecnologia do
Ceará.
1. Banco de Dados 2. SGBDD 3. Cluster
4. Middleware. Universidade Estadual do Ceará,
Centro de Ciências e Tecnologia.
CDD: 001.6

Título do trabalho: Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos
Autor: Cicero Tadeu Pereira Lima França
Defesa em: 01/09/2010
Banca Examinadora
Cidcley Teixeira de Souza, DSc (IFCE)
Presidente (Orientador)
Verônica Lima Pimentel de Sousa, DSc (IFCE)
Membro Interno
José Maria da Silva Monteiro Filho, DSc (UFC)
Membro Externo

À minha esposa Ylane, e aos meus filhos Lucas Gabriel e Cibelle.

Agradecimentos
À DEUS, que sempre mostra o caminho correto em momentos incertos.
À minha esposa Ylane pelo apoio irrestrito em todos os momentos, sempre elevando
minha auto-estima nas horas difíceis.
Ao meu filho Lucas Gabriel que, mesmo com três anos de idade, aceitava as
ausências do pai durante este mestrado.
À minha filha Cibelle, que nasceu no mesmo período da defesa desta dissertação.
À minha mãe Terezinha, por sempre ter ensinado aos filhos que o estudo é
importante na vida das pessoas.
À minha tia-madrinha Cicera, pelo acolhimento e carinho que sempre me foi dado.
À minha já falecida avó materna Quitéria, pelo exemplo de bondade e serenidade.
Ao meu orientador Prof. Cidcley Teixeira de Souza, pelo tempo dedicado no
direcionamento e incentivo, sempre apoiando nos momentos mais difíceis.
Ao MPCOMP, aos que representam a coordenação, Prof. Marcos Negreiros, Profa.
Verônica Pimentel, Prof. Klécius, e aos secretários Ton e Érika, meus sinceros
agradecimentos pelo apoio institucional no final desta caminhada.
Ao IFCE – Campus Juazeiro do Norte, por proporcionar as condições de trabalho na
fase final deste trabalho.

Resumo
Este trabalho apresenta um middleware para ser utilizado com SGBDRs (Sistemas
de Gerenciamento de Bancos de Dados Relacional) que usam a arquitetura cliente-servidor
de duas camadas. O middleware tem a finalidade de aumentar a eficiência dos SGBDRs em
relação a escalabilidade, através do gerencia de um cluster de SGBDRs.
Os SGBDRs com arquitetura cliente-servidor de duas camadas têm como
desvantagem a baixa escalabilidade. A única maneira de aumentar a escalabilidade de um
SGBDR nesse tipo de arquitetura é trocando o servidor de dados por outro com poder
computacional maior. O middleware apresentado neste trabalho aumenta a escalabilidade
dos SGBDRs citados, gerenciando a distribuição horizontal dos dados e mantendo o
balanceamento de carga dentro do cluster de SGBDRs.
Palavras-chave: Banco de Dados, SGBDR, Cluster, Middleware, Distribuição de
Dados, Balanceamento de Carga.

Abstract
This project shows a middleware to be used with RDBMS (Relational Database
Management System) that use the client-server architecture of two tier. The middleware has
a the objective to increase the efficiencies of the RDBMS in order to a relation with scales,
through a RDBMS cluster management.
The RDBMS with client-server architecture of two tier has as an disadvantage the
low scales. The only way to increase the scale of a RDBMS n this type of architecture is
changing the data servers by another one with a bigger computer power. The middleware
shown in this project increases the scales of the mentioned RDBMS, managing the
horizontal data distribution and keeping the balance inside the cluster of RDBMS.
Keywords: Database, RDBMS, Cluster, Middleware, Data Distribution, Load
Balancing.

Lista de Figuras
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
Figura 2.1 – A arquitetura física centralizada
Figura 2.2 – A arquitetura física cliente/servidor de duas camadas
Figura 2.3 – A arquitetura lógica cliente/servidor de três camadas
Figura 2.4 – Um elemento XML complexo chamado <projetos>
Figura 3.1 – Arquitetura física Real Application Clusters
Figura 3.2 – Sistema de balanceamento de carga
Figura 3.3 – Sistema de alta disponibilidade
Figura 3.4 – Replicação em Cascata
Figura 3.5 – Replicação continua após uma falha
Figura 3.6 – Arquitetura do ParGRES
Figura 3.7 – Arquitetura do modelo de mediador proposto por Tercilio Junior
Figura 3.8 – Exemplo de RAIDb-0
Figura 3.11 – Exemplo de RAIDb-1-0
Figura 3.12 – Exemplo de RAIDb-0-1
Figura 4.1 – Middleware proposto
Figura 4.2 – Diagrama de caso de uso sintético
Figura 4.3 – Diagrama de caso de uso básico
Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware
Figura 4.5 – Diagrama de classe do LUCAS
Figura 4.6 – Diagrama de classe do GABRIEL
Figura 4.7 – Diagrama de Seqüência – Incluir registro independente
Figura 4.8 – Diagrama de Seqüência – Incluir registro dependente
Figura 4.9 – Fluxograma para inclusão de dados
Figura 4.10 – Diagrama de Seqüência – Alterar registro
Figura 4.11 – Fluxograma para alteração de dados
Figura 4.12 – Diagrama de Seqüência – Excluir registro

Figura 4.13 – Fluxograma para exclusão de dados
Figura 4.14 – Diagrama de Seqüência – Consultar via SetConsultar
Figura 4.15 – Fluxograma para consultar dados via SetConsultar
Figura 4.16 – Diagrama de Seqüência – Consultar via SetConsultarSQL
Figura 5.1 – Aplicativo GABRIEL
Figura 5.2 – Aplicativo Cliente
Figura 5.3 – Aplicativo Configura Cliente
Figura 5.4 – Gráfico do percentual médio de desempenho da CPU na inclusão de dados
Figura 5.5 – Gráfico do percentual médio da utilização da rede na inclusão de dados
Figura 5.6 – Gráfico do percentual médio de desempenho da CPU na alteração de dados
Figura 5.7 – Gráfico do percentual médio da utilização da rede na alteração de dados
Figura 5.8 – Gráfico do percentual médio de desempenho da CPU na consulta de dados
Figura 5.9 – Gráfico do percentual médio da utilização da rede na consulta de dados

Lista de Tabelas
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Tabela 2.2 – Exemplo de fragmentação horizontal
Tabela 2.3 – Exemplo de fragmentação vertical
Tabela 4.1 – Incluir registro independente
Tabela 4.2 – Incluir registro dependente
Tabela 4.3 – Alterar registro
Tabela 5.1 – Percentual médio de desempenho da CPU no processo de inclusão de dados
Tabela 5.2 – Percentual médio da utilização da rede no processo de inclusão de dados
Tabela 5.3 – Tabelas dos SGBDRs após o processo de inclusão de dados
Tabela 5.4 – Percentual médio de desempenho da CPU no processo de alteração de dados
Tabela 5.5 – Percentual médio da utilização da rede no processo de alteração de dados
Tabela 5.6 – Percentual médio de desempenho da CPU no processo de consulta de dados
Tabela 5.7 – Percentual médio da utilização da rede no processo de consulta de dados
Tabela A.1 – Atributos da classe LUCAS
Tabela A.2 – Métodos da classe LUCAS
Tabela B.1 – Atributos da classe ClientSocket
Tabela B.2 – Métodos da classe ClientSocket
Tabela C.1 – Atributos da classe GABRIEL
Tabela C.2 – Métodos da classe GABRIEL
Tabela D.1 – Atributos da classe ServerSocket
Tabela D.2 – Métodos da classe ServerSocket
Tabela E.1 – Atributos da classe SQLConnect
Tabela E.2 – Métodos da classe SQLConnect
Tabela G.1 – Chamadas aos métodos da classe LUCAS
Tabela G.2 – Métodos auxiliares utilizados na sobrecarga
Tabela G.3 – Resumo das configurações dos computadores usados no teste

Lista de Abreviaturas
ANSI American National Standards Institute
API Application Program Interface
BDD Banco de Dados Distribuído
CQP Cluster Query Processor
CRM Customer Relationship Management
DBA Database Administrator
DCL Data Control Language
DDL Data Definition Language
DML Data Manipulation Language
DQL Data Query Language
DTL Data Transaction Language
ERP Enterprise Resource Planning
ISO International Organization for Standardization
JDBC Java Database Connectivity
JDK Java Development Kit
JVM Java Virtual Machine
LAN Local Area Network
NQP Node Query Processor
ODBC Open Data Base Connectivity
POO Programação Orientada a Objeto
RAC Real Application Cluster
RAID Redundant Array of Inexpensive Drives
RAIDb Redundant Array of Inexpensive Databases
SEQUEL Structured English Query Language
SGBD Sistema Gerenciador de Banco de Dados
SGBDD Sistema Gerenciador de Banco de Dados Distribuído
SGBDOR Sistema de Gerenciamento de Bancos de Dados Objeto-Relacional
SGBDR Sistema Gerenciador de Bancos de Dados Relacional
SOA Service Oriented Architecture

SQL Structured Query Language
UML Unified Modeling Language
XML eXtensible Markup Language
W3C World Wide Web Consortium
WAN Wide Area Network
WWW World Wide Web

Sumário
Capítulo 1................................................................................................................................1
Introdução ...............................................................................................................................1
1.1. Motivação ................................................................................................................1
1.2. Descrição do Problema ...........................................................................................2
1.3. Solução Proposta.....................................................................................................3
1.4. Organização da Dissertação ...................................................................................4
Capítulo 2................................................................................................................................5
Fundamentação Teórica..........................................................................................................5
2.1. Computação Distribuída..........................................................................................5
2.1.1. Comunicação entre Processos..............................................................................5
2.1.1.1. Comunicação Síncrona e Assíncrona................................................................6
2.1.1.2. Troca de Mensagens ..........................................................................................6
2.1.1.3. Falhas de Comunicação ....................................................................................7
2.1.1.4. Transmissão de Mensagens por Sockets............................................................7
2.1.2. Cluster...................................................................................................................8
2.1.3. Grid Computing ....................................................................................................9
2.1.3.1. Diferenças entre Cluster e Grid Computing....................................................10
2.1.4.Middleware ..........................................................................................................10
2.2. Banco de Dados.....................................................................................................11
2.2.1. Banco de Dados e Sistema Gerenciador de Banco de Dados ............................11
2.2.2. Modelos de Bancos de Dados.............................................................................12
2.2.3. Arquiteturas de Banco de Dados........................................................................13
2.2.3.1. Arquitetura Centralizada.................................................................................13
2.2.3.2. Arquitetura Cliente-Servidor de Duas Camadas.............................................13
2.2.3.3. Arquitetura Cliente-Servidor de Três Camadas ..............................................14
2.2.3.4. Arquitetura Distribuída ...................................................................................15
2.2.3.4.1. Vantagens......................................................................................................16
2.2.3.4.2. Desvantagens................................................................................................16
2.2.3.4.3. Fragmentação de Dados...............................................................................16
2.2.3.4.4. Replicação de Dados ....................................................................................18
2.2.4. SQL .....................................................................................................................19
2.2.5. XML ....................................................................................................................20
2.3. Conclusão ..............................................................................................................21
Capítulo 3..............................................................................................................................23
Trabalhos Relacionados........................................................................................................23
3.1. Oracle 10g .............................................................................................................23
3.1.1. Real Application Cluster.....................................................................................23
3.1.1.1. Arquitetura do Real Application Cluster.........................................................24
3.1.2. Oracle Clusterware.............................................................................................24
3.1.3. Escalabilidade ....................................................................................................25
3.1.4. Pontos Fracos na Solução da Oracle 10g..........................................................25
3.2. PostgreSQL............................................................................................................25

3.2.1. PGCluster ...........................................................................................................25
3.2.2. PGPool................................................................................................................27
3.2.3. Slony-I.................................................................................................................27
3.2.4. ParGRES.............................................................................................................29
3.2.4.1. Arquitetura.......................................................................................................30
3.2.4.2. Cluster Query Processor .................................................................................30
3.2.5. Pontos Fracos nas Soluções do PostgreSQL......................................................30
3.3. Modelo para o Compartilhamento de Bases de Dados Distribuídas e
Heterogêneas ................................................................................................................30
3.3.1. Atores..................................................................................................................31
3.3.2. Classes ................................................................................................................32
3.3.3. Pontos Fracos do Middleware............................................................................33
3.4. Sequoia...................................................................................................................33
3.4.1. Arquitetura..........................................................................................................33
3.4.2. RAIDb .................................................................................................................33
3.4.2.1. RAIDb-0...........................................................................................................34
3.4.2.2. RAIDb-1...........................................................................................................34
3.4.2.3. RAIDb-2...........................................................................................................35
3.4.2.4. Aninhamento de RAIDb ...................................................................................35
3.4.3. Pontos Fracos do Sequoia ..................................................................................35
3.5. Conclusão ..............................................................................................................36
Capítulo 4..............................................................................................................................38
O Middleware LUCAS-GABRIEL ......................................................................................38
4.1. Introdução..............................................................................................................38
4.2. Diagrama de caso de uso.......................................................................................39
4.3. Diagrama de classe ...............................................................................................42
4.3.1. LUCAS ................................................................................................................42
4.3.2. GABRIEL ............................................................................................................44
4.4. Diagrama de seqüência .........................................................................................45
4.4.1. Incluir..................................................................................................................45
4.4.1.1. Incluir registro independente...........................................................................45
4.4.1.2. Incluir registro dependente..............................................................................49
4.4.2. Alterar.................................................................................................................53
4.4.3. Excluir.................................................................................................................55
4.4.4. Consultar ............................................................................................................57
4.4.4.1. SetConsultar.....................................................................................................57
4.4.4.2. SetConsultarSQL .............................................................................................58
4.5. Fluxos alternativos e Funcionalidade ...................................................................59
4.6. Conclusão ..............................................................................................................60
Capítulo 5..............................................................................................................................62
Validação ..............................................................................................................................62
5.1. DLL “LUCAS” ......................................................................................................62
5.2. Aplicativo “GABRIEL” .........................................................................................62
5.3. Aplicativo “Cliente”..............................................................................................63
5.4. Aplicativo “Configura Cliente”.............................................................................64
5.5. Cenário ..................................................................................................................64
5.6. Casos de Validação ...............................................................................................65

5.6.1. Incluir Dados ......................................................................................................66
5.6.2. Alterar Dados .....................................................................................................70
5.6.3. Consultar Dados.................................................................................................71
5.7. Análise da validação..............................................................................................73
5.8. Conclusão ..............................................................................................................74
Capítulo 6..............................................................................................................................75
Conclusão e Trabalhos Futuros.............................................................................................75
6.1. Síntese da Dissertação...........................................................................................75
6.2. Conclusão ..............................................................................................................75
6.2.1. Vantagens do Middleware ..................................................................................76
6.2.2. Limitações do Middleware..................................................................................77
6.3. Dificuldades Encontradas......................................................................................77
6.4. Trabalhos Futuros .................................................................................................78
Apêndice A ...........................................................................................................................80
Apêndice B ...........................................................................................................................84
Apêndice C ...........................................................................................................................86
Apêndice D ...........................................................................................................................90
Apêndice E............................................................................................................................91
Apêndice F............................................................................................................................93
Apêndice G ...........................................................................................................................95
Referências............................................................................................................................98

1
Capítulo 1
Introdução
Nos tempos atuais a informação é um bem imprescindível. Contudo deve-se unir a
isso a necessidade de obtê-las de maneira eficiente e rápida. Este cenário leva ao
nascimento de muitas idéias com o intuito de aperfeiçoar (i) o armazenamento de dados e
(ii) a busca por um processo eficiente para fazer o armazenamento de dados.
1.1. Motivação
Com o fim da reserva de mercado para produtos de informática – Lei Federal
nº 8.248/91 – o parque computacional empresarial no Brasil começou a “existir”. Até então
raras empresas tinham um ou mais computadores.
Levando este cenário para o lado das redes de computadores a situação se agravava.
Se empresas com um computador era fato raro e com mais de um computador fato
raríssimo, o que falar das empresas que tinham mais de um computador e que os ligavam
em rede? Hoje é inimaginável uma empresa não interligar seus computadores numa rede de
computadores, mas no início da década de 1990 isso era muitas vezes tratado com descaso.
A quase inexistência de redes computacionais vinha de vários fatores. Um dos
fatores mais importante eram os softwares, uma vez que os mesmos eram criados para
automatizar processos, mas esses processos automatizados não eram integrados. Cada setor
tinha seu próprio software que armazenava suas próprias informações e essas informações
não eram compartilhadas por outros setores da mesma empresa.
Quase duas décadas depois este cenário mudou consideravelmente. Nos dias atuais
raramente encontra-se uma empresa no Brasil que não tenha um ou mais computadores. As
informações são compartilhadas entre os vários setores da empresa, o que elevou as redes
de computadores para o nível de tecnologia essencial no mundo empresarial.
Por outro lado, as empresas sabem que os dados armazenados podem e devem ser
convertidos em dividendos. Manter os dados em locais seguros é visto por alguns como
uma estratégia de mercado, mas não basta apenas mantê-los seguros, a empresa tem que ser
capaz de acessar esses dados.

2
A busca e cruzamento dos dados armazenados podem gerar novas oportunidades de
negócios. Por este motivo, todo esforço físico imposto no armazenamento de dados de nada
servirá, caso o empresário não tenha como obter esses dados de maneira fácil e rápida.
A agilidade na obtenção dos dados pode ser afetada pela tecnologia e arquitetura de
armazenamento de dados utilizada. Os SGBDRs com arquitetura cliente-servidor de duas
camadas são amplamente usados na atualidade, mas esses tipos de SGBDs têm como
desvantagem baixa escalabilidade.
As soluções existentes, para resolver a baixa escalabilidade dos SGBDRs com
arquitetura cliente-servidor de duas camadas. Essas soluções são onerosas, pois requerem a
aquisição de licenças caras de SGBD, ou a alteração dos sistemas já implantados na
empresa, ou ainda a criação de uma estrutura de hardware. As empresas de pequeno e
médio porte não têm o aporte financeiro necessário para adotarem as soluções existentes.
Este trabalho propõe uma solução, para resolver o problema de escalabilidade, menos
onerosa que as soluções existentes.
1.2. Descrição do Problema
Com o aumento da necessidade de armazenamento de grandes volumes de dados,
problemas e soluções foram surgindo. Um deles está relacionado com sistemas
centralizados de Maiframe e com hardwares capazes de armazenar e processar grandes
volumes de dados.
A criação de softwares capazes de manter grandes volumes de dados seguros e
disponíveis, também passou a ser uma necessidade, pois a perda de dados poderia ocasionar
danos, dependendo do domínio onde os dados estavam sendo usados.
Para ilustrar este cenário, idealize uma pane no armazenamento de dados da bolsa
de valores de Nova York, onde os valores das ações negociadas desaparecessem, e a sua
recuperação não fosse possível. A desordem se instalaria no sistema financeiro mundial.
Constatou-se que o armazenamento de dados mais comum, entre as pequenas e
médias empresas, utiliza o modelo de bancos de dados relacional com arquitetura
cliente-servidor de duas camadas. Nessa arquitetura, vários clientes ficam conectados em
um único servidor (figura 1.1). A grande vantagem dessa arquitetura é a facilidade do
gerenciamento centralizado dos dados, mas, em contrapartida, o servidor é responsável por
armazenar todos os dados num único ponto.

3
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
A falta de escalabilidade é um problema que impacta diretamente sobre a rotina
diária das empresas. Com o constante aumento no volume de dados e na quantidade de
clientes conectados no servidor, as solicitações de manipulação e consultas dos dados
passam a sofre degradação no seu processamento.
As grandes empresas conseguem resolver o problema de escalabilidade com
investimentos financeiros altos, adquirindo licenças de softwares ou infra-estrutura de
hardware. As pequenas e médias empresas não têm como investir valores elevados para
reverter esse problema. Mas independente do tamanho da empresa, a escalabilidade é um
problema presente e sua solução merece atenção, pois a agilidade na obtenção dos dados é
tão importante para a tomada de decisão quanto a disponibilidade dos dados.
1.3. Solução Proposta
O middleware proposto nesta dissertação tem como foco principal a escalabilidade
associada a independência do SGBDR. Ele soluciona o problema de escalabilidade numa
estrutura de armazenamento de dados que pode ser tanto homogênea quanto heterogênea. O
problema de escalabilidade é resolvido através da distribuição dos dados horizontalmente
entre várias instâncias de SGBDRs sem interferir, contudo, na maneira como os dados são
gerenciados nesses servidores.
O middleware trata o problema de escalabilidade dos SGBDRs com arquitetura
cliente-servido de duas camadas. Para isso o middleware fornecerá um ambiente de
distribuição de dados, possibilitará um acesso simplificado aos dados distribuídos e tornará
Cliente Cliente Cliente Cliente Cliente
Servidor
Memória

4
a distribuição destes dados transparentes aos outros sistemas. O middleware simplificará as
solicitações, proporcionando a interação entre os sistemas clientes e os dados distribuídos
de maneira transparente.
1.4. Organização da Dissertação
No capítulo 2 são apresentados fundamentos teóricos, tais como os conceitos de
comunicação entre processos, troca de mensagem, transações concorrentes e uma visão
geral sobre cluster e grid computing. Banco de dados e suas principais características,
alguns modelos de banco de dados e as arquiteturas de banco de dados mais comuns,
também estão contidos no capítulo 2.
A arquitetura do banco de dados Oracle 10g com a tecnologia baseada em grid
computing, desenvolvida para dar suporte aos componentes que oferecem alta
disponibilidade, escalabilidade, e proteção contra falhas é apresentada no capítulo 3. Este
capítulo discute ainda o banco de dados PostgreSQL com suas soluções para os mesmos
problemas, assim como o middleware Sequoia e um modelo para o compartilhamento de
bases de dados distribuídas.
O middleware proposto é apresentado no capítulo 4. Sua validação, a descrição do
ambiente de teste, os casos de teste e os resultados são mostrados no capítulo 5.
No último capítulo são apresentados algumas considerações finais, além das
conclusões obtidas, dificuldade encontradas e os trabalhos futuros a serem realizados.

5
Capítulo 2
Fundamentação Teórica
Antes de apresentar o middleware proposto, se torna necessário esclarecer alguns
conceitos básicos que levaram a concepção desta proposta. Como o middleware proposto
tem a finalidade de gerenciar a distribuição do armazenamento de dados entre banco de
dados homogêneos e/ou heterogêneos, duas áreas do conhecimento – Computação
Distribuída e Banco de Dados – devem ser apresentadas para o melhor entendimento da
solução proposta.
2.1. Computação Distribuída
Nesta seção são discutidos alguns conceitos sobre sistemas distribuídos. Não é
pretensão desta seção exaurir o tema, uma vez que alguns dos tópicos apresentados têm
informações e contestações suficientes para justificar a quantidade de livros, artigos, entre
outras publicações acadêmicas.
2.1.1. Comunicação entre Processos
Processos que rodam em vários sistemas finais podem comunicar-se. Segundo
[KUROSE, 2006] “Um processo pode ser imaginado como um programa que está rodando
dentro de um sistema final.”. Quando os processos estão rodando no mesmo sistema final é
usada a comunicação interprocessos que é resolvida pelo sistema operacional final que
define suas regras com base na proposta do seu projeto de criação e desenvolvimento.
“ o contexto de uma sessão de comunicação entre um par de processos,
o processo que inicia a comunicação (isto é, o primeiro a contatar o
outro no início da sessão) é rotulado como cliente. O processo que
espera ser contatado para iniciar a sessão é o servidor.”
[KUROSE, 2006].

6
2.1.1.1. Comunicação Síncrona e Assíncrona
Nas comunicações síncronas quando o processo a envia (send) a mensagem o
mesmo fica bloqueado até receber (receive) a mensagem de resposta do processo b. Nesse
caso o send e receive causam bloqueio no processo.
Nesse tipo de comunicação (i) o processo remetente envia uma mensagem de
requisição pedindo autorização para iniciar a transmissão; (ii) recebendo a autorização o
processo remetente inicia o envio (send) da mensagem; (iii) o envio (send) só é concluído
após a recepção (receive) confirmando o recebimento; (iv) após concluir o processo os
buffers e estruturas de dados são liberados.
Necessitando-se de um processo que após o envio da mensagem (send) não fique
bloqueado pela recepção (receive), deve-se utilizar a comunicação assíncrona. Nesse caso a
operação send é não bloqueante. Enquanto o receive pode tanto ser bloqueante quanto não
bloqueante.
No receive bloqueante o send é liberado após a mensagem ter sido copiada para um
buffer local. Em seguida, o processo remetente pode reutilizar o seu buffer, mas não tendo
como garantia o sucesso da transmissão anterior. O receive da comunicação assíncrona
bloqueante assemelha-se com o receive da comunicação síncrona.
“ a variante não bloqueante, o processo destino prossegue sua
execução após ter realizado a operação receive, a qual fornece um
buffer para ser preenchido em background. este caso, o processo deve
receber separadamente uma notificação de que seu buffer possui dados a
serem lidos, isso pode ser feito baseado em polling ou em interrupção.”
[COULOURIS, 2007].
2.1.1.2. Troca de Mensagens
Quando se deseja criar uma comunicação entre um processo cliente e servidor
pode-se usar a troca de mensagem. Essas mensagens trocadas devem ter um protocolo de
comunicação, uma vez que, para obter o resultado esperado, esse processo requer uma
compreensão e cooperação entre o processo cliente e servidor.
Segundo [TANENBAUM, 2003] “Este método de comunicação interprocessos usa
duas primitivas, send e receive.”. O processo remetente envia uma solicitação ao processo
destino via mensagem. Ao receber a mensagem o processo servidor avalia para iniciar o

7
atendimento a solicitação ou, caso a mensagem seja inconsistente, retorna uma mensagem
de erro ao processo cliente.
2.1.1.3. Falhas de Comunicação
Um problema que deve ser levado em consideração nos sistemas que usam troca de
mensagem é a possibilidade de perdas de mensagens, “especialmente se os processos
comunicantes estiverem em máquinas diferentes conectadas por uma rede.”
[TANENBAUM, 2003].
O modelo de falha apresentado por [COULOURIS, 2007] classifica as falhas a
seguir:
• Falhas por Omissão: Falhas provenientes de problemas na execução em um
canal de comunicação ou processo.
• Falhas Arbitrárias: A falha no (i) processo acontece quando passos do
processo são omitidos ou são efetuados processamentos indesejados. A falha
no (ii) canal de comunicação aparece quando uma mensagem é corrompida,
mensagens inexistentes são enviadas ou mensagens reais são entregues mais
de uma vez.
• Falhas de Temporização: Só existem nos sistemas síncronos que precisam
da garantia de temporização.
• Mascaramento de Falhas: Falhas conhecidas de um componente do sistema,
ocultadas ou convertidas num tipo de falha aceitável através do
mascaramento.
• Confiabilidade da Comunicação de Um para Um: Falhas na validação e
integridade das mensagens.
2.1.1.4. Transmissão de Mensagens por Sockets
Quando o processo emissor está fisicamente separado do processo receptor, essa
comunicação pode fazer uso de socket sobre uma rede com protocolo TCP/IP, pois o
mesmo combina o endereço de IP, o protocolo de comunicação e a porta que será usada.
“Um processo envia mensagens para a rede e recebe mensagens dela através de um socket.”
[KUROSE, 2006].
Os três tipos de sockets mais comuns são:

8
1. Fluxo confiável de bytes orientado a conexão;
2. Fluxo confiável de pacotes orientado a conexão;
3. Transmissão não confiável de pacotes.
No primeiro tipo de socket os bytes são enviados do emissor para o receptor de
maneira continua, e garante que todos os bytes enviados vão ser recebidos na ordem em que
foram enviados.
O segundo tipo de socket é semelhante ao primeiro, mas neste caso os bytes não
serão transmitidos de uma única vez, e sim em pacotes com tamanhos bem definidos.
O terceiro tipo de socket é muito usado em aplicativos de tempo real ou em sistema
com tratamento de erro implementado no seu projeto. Nesse tipo de socket não existe a
garantia de ordem nem a garantia de entrega dos pacotes, sendo indicado para os
aplicativos onde a exigência de desempenho sobrepõe a confiabilidade dos bytes enviados e
recebidos.
2.1.2. Cluster
Cluster, ou aglomerado de computadores, pode ser definido como um grupo de
computadores que trabalham de maneira que aparentam ser uma única máquina. Para isto,
deve ser utilizado um sistema operacional distribuído. O sistema operacional distribuído “é
aquele que parece aos olhos dos usuários um sistema operacional tradicional de processador
único...” [TANENBAUM, 2003].
Outra definição de cluster, sob a ótica de redes de computadores, é apresentada por
[COULOURIS, 2007].
“Um agrupamento, ou aglomerado, é um conjunto de computadores
convencionais... interligado por uma rede de comunicação de alta
velocidade... comutada. Os computadores individuais podem ser PCs,
estações de trabalho padrão, placas de processador montadas sobre um
rack; eles ainda podem ser monoprocessadores ou multiprocessadores.
Uma aplicação de clusters é o fornecimento de serviços de alta
disponibilidade e flexíveis... pela replicação ou divisão do
processamento e do estado do servidor em todos processadores do
cluster... também são usados para executar programas paralelos”
[COULOURIS, 2007].

9
A evolução das redes de computadores, capacitando ligar vários computadores em
uma rede e permitindo-os que desempenhem uma mesma tarefa, impulsionou o uso e
evolução do cluster ao estágio atual, onde o cluster se tornou uma opção interessante nos
departamentos de tecnologia das corporações.
2.1.3. Grid Computing
A idéia de um modelo capaz de lidar com uma taxa de processamento elevada e ao
mesmo tempo dividir esse processamento entre máquinas formando uma única máquina
virtual, podendo ser acessada por uma LAN (Local Area etwork – Rede de Área Local) ou
WAN (Wide Area etwork – Rede de Longa Distância), foi introduzida nos anos 90 com o
grid computing.
A analogia com as redes elétricas (power grids) é citada sempre que se deseja falar
sobre grid computing. No caso das redes elétricas, quando se tem um equipamento que
necessita de energia elétrica, basicamente, basta conectar na rede elétrica e a mesma
proverá a energia necessária para o funcionamento do equipamento. Não é preciso saber de
onde vem, em que momento foi gerada ou como foi transportada. A única coisa que
interessa é que tenha o que se deseja – energia elétrica – no momento que se precisa.
Da mesma maneira deve ser o grid computing, quando se precisar armazenar ou
recuperar informações, processar uma quantidade relativamente grande de dados entre
outros tantos recursos computacionais, basta conectar a máquina no grid computing e o
mesmo proverá o que se deseja no momento que se precisa.
“O termo grade (grid) é usado para se referir ao middleware que é
projeto para permitir o compartilhamento de recursos como arquivos,
computadores, software, dados e sensores em uma escala muito grande.
ormalmente, os recursos são compartilhados por grupos de usuários
em diferentes organizações, os quais estão colaborando na solução de
problemas que exigem grandes números de computadores para resolvê-
los, ou pelo compartilhamento de dados ou pelo compartilhamento do
poder de computação. Esses recursos são necessariamente suportados
por hardware, sistemas operacionais, linguagens de programação e
aplicações heterogêneas. É necessário gerenciamento para coordenar o
uso de recursos para garantir que os clientes obtenham o que precisam e

10
que os serviços possam fornecê-los. Em alguns casos, são exigidas
técnicas de segurança sofisticadas para garantir o uso correto dos
recursos nesse tipo de ambiente.” [COULOURIS, 2007].
2.1.3.1. Diferenças entre Cluster e Grid Computing
Embora possam parecer iguais à primeira vista, cluster e grid computing são
diferentes na sua essência.
Quanto ao gerenciamento de recurso:
• Cluster – Gerenciamento centralizado, tendo todos os nós trabalhando em
conjunto buscando um objetivo comum.
• Grid Computing – Gerenciamento descentralizado, onde cada nó pode adotar
políticas de alocação e uso de recursos, independente das políticas adotada
por outros nós.
Quanto à especificação do hardware e software:
• Cluster – Têm que ser homogêneos.
• Grid Computing – Têm que ser heterogêneos.
Quanto à conexão:
• Cluster – Requer tecnologia de redes de computadores de alto-desempenho
(“system bus”, iSCSI, Fibre Channel).
• Grid Computing – Permite redes convencionais de internet.
2.1.4.Middleware
Um middleware é um software que pode gerar a troca de informações entre
programas com diferentes (i) protocolos de comunicação, (ii) sistemas operacionais e (iii)
plataformas. O middleware também fornece uma estrutura de programação mais rica e
produtiva, facilitando (i) o desenvolvimento de aplicações distribuídas e a (ii) integração de
sistemas legados.
O middleware, geralmente, contém módulos com APIs (Application Program
Interface – Interface de Programação de Aplicativo) de alto nível para facilitar a integração
entre os aplicativos, mantendo uma interface de baixo nível para comportar a
independência de dispositivo.

11
Embora alguns middleware só suportem uma linguagem de programação,
comumente, o middleware é uma camada de software que oferece abstração de
programação.
“O middleware foi definido... como uma camada de software cujo o
objetivo é mascarar a heterogeneidade e fornecer um modelo de
programação conveniente para os programadores de aplicativos... Em
particular, ele simplifica as atividades de comunicação de programas
aplicativos por meio do suporte de abstração como a invocação a
métodos remotos, a comunicação entre um grupo de processos, a
notificação de eventos, o particionamento, posicionamento e
recuperação de objetos de dados compartilhado entre computadores, a
replicação de objetos de dados compartilhados e a transmissão de dados
multimídia em tempo real.” [COULOURIS, 2007].
2.2. Banco de Dados
Esta seção apresenta alguns tópicos sobre banco de dados que devem ser
conhecidos, uma vez que a arquitetura proposta foi criada para distribuir de maneira
balanceada os dados armazenados.
2.2.1. Banco de Dados e Sistema Gerenciador de Banco de Dados
A diferença entre banco de dados e Sistema Gerenciador de Banco de Dados
(SGBD) deve ficar bem clara para entender os conceitos que se seguem.
Um banco de dados deve ser projetado para o armazenamento de fatos que possuem
um significado implícito, representando aspectos do mundo real. O conjunto de
informações (dados) armazenado deve ter um significado efetivo que atende um propósito
específico.
“... um banco de dados possui algumas fontes das quais os dados são
derivados, alguns níveis de interação com os eventos do mundo real e um
publico efetivamente interessado em seus conteúdos.” [ AVATHE,
2005].
Um SGBD é um conjunto de programas que permite a criação e manipulação do
banco de dados, facilitando os processos de definição, construção, manipulação e
compartilhamento dos dados.

12
De uma maneira simplista, um banco de dados especifica os dados, as estruturas e
as restrições enquanto o SGBD gerencia a manipulação desses dados facilitando o acesso
aos mesmos, extraindo essas responsabilidades dos usuários e aplicativos.
2.2.2. Modelos de Bancos de Dados
À medida que aumentava o uso de banco de dados, foram surgindo necessidades
que antes não eram vislumbradas, com isso antigos modelos de banco de dados foram
cedendo espaços para novos modelos, causando uma evolução nos bancos de dados. Na
seqüência são mostrados alguns modelos de banco de dados e suas características
principais:
• Banco de Dados Hierárquico: Esse modelo foi muito utilizado nas primeiras
aplicações de banco de dados; ele conecta registros numa estrutura de árvore
de dados através de um relacionamento do tipo um-para-muitos.
• Banco de Dados em Rede: Semelhante ao anterior, mas nesse caso o
relacionamento é do tipo muitos-para-muitos.
• Banco de Dados Relacional: Concebido inicialmente para separar o modelo
físico do conceitual, além de prover uma fundamentação matemática; sendo
um modelo baseado na lógica e na teoria de conjuntos tornou-se o primeiro
modelo de banco de dados formal; esse modelo é uma abstração que define o
armazenamento, manipulação e recuperação dos dados estruturados na forma
de tabelas; sendo largamente utilizado nos dias atuais.
• Banco de Dados Orientado a Objeto: Esse modelo foi criado pensando na
necessidade do armazenamento e consulta de dados complexos,
incorporando paradigmas já conhecidos da programação orientada a objeto
(POO), tais como a abstração de dados, encapsulamento, herança e
identificação de objetos.
• Banco de Dados Objeto-Relacional: Esse modelo é semelhante ao modelo
relacional, mas alguns conceitos do modelo orientado a objeto foram
incorporados; os esquemas do banco de dados dão suporte à criação e
consulta de objetos, classes e herança.

13
2.2.3. Arquiteturas de Banco de Dados
Assim como os modelos, no decorrer do tempo foram propostas varias arquiteturas.
As principais arquiteturas que foram propostas e ainda são usadas são apresentadas nesta
subseção.
2.2.3.1. Arquitetura Centralizada
As arquiteturas dos bancos de dados centralizados (figura 2.1) utilizavam o conceito
de concentrar nos mainframes o processamento das funções do sistema, programas de
aplicação, programas de interface entre outras funcionalidades do SGBD.
Figura 2.1 – A arquitetura física centralizada – Fonte: [ AVATHE, 2005]
Os usuários acessavam os sistemas via terminais de computadores que apenas
exibiam resultados, mas não tinham poder computacional de processamento. Os processos
em si eram executados remotamente no mainframe, que após processar o solicitado,
enviava ao terminal as informações de exibição e os controles.
2.2.3.2. Arquitetura Cliente-Servidor de Duas Camadas
Essa arquitetura (figura 2.2) é uma evolução da arquitetura centralizada, pois graças
à troca dos antigos terminais cliente por PCs e workstations o poder computacional do lado
cliente aumentou, possibilitando passar parte do processamento para os mesmos e

14
“desafogando” os servidores. Os programas de interface com o usuário e os de aplicação
foram transpostos para o lado cliente.
Figura 2.2 – A arquitetura física cliente/servidor de duas camadas – Fonte: [ AVATHE, 2005]
Um cliente é geralmente uma máquina de usuário com poder computacional e com
funcionalidade de interfaces, mas sempre que precisar acessar o banco de dados conecta-se
com o servidor que viabiliza o acesso aos dados. Geralmente têm-se máquinas com
software cliente e outras com software servidor, mas pode-se ter máquinas com ambos.
Na arquitetura cliente-servidor o programa cliente estabelece uma conexão com o
programa servidor para comunicar-se com o SGBD. Após estarem conectados, os sistemas
cliente enviam solicitações de manipulação e consulta dos dados, as mesmas são
processadas pelo servidor e enviadas de volta para o programa cliente, que processa e
apresenta o resultado de acordo com a necessidade.
2.2.3.3. Arquitetura Cliente-Servidor de Três Camadas
Com o crescimento da WWW (World Wide Web – Rede de Alcance Mundial – ou
simplesmente Web) os papéis na arquitetura cliente-servidor de duas camadas sofreram
mudanças que levaram a arquitetura cliente-servidor de duas camadas para a arquitetura
cliente-servidor de três camadas (figura 2.3), ou arquitetura de três camadas. Na arquitetura
de três camadas foi colocada uma camada intermediaria entre a máquina cliente e o

15
servidor de banco de dados. Essa camada do meio passou a chamar-se de servidor de
aplicação ou servidor Web, dependendo do contexto onde o aplicativo está inserido.
Figura 2.3 – A arquitetura lógica cliente/servidor de três camadas – Fonte: [ AVATHE, 2005]
“Esse servidor desempenha um papel intermediário armazenando as regras de
negócio... que são usadas para acessar os dados do servidor de banco de dados.”
[NAVATHE, 2005]. Checar as credenciais do cliente antes de aceitar a solicitação do
mesmo também pode ser incrementado nesse servidor, deixando por sua conta a segurança
do banco de dados, desafogando o servidor de banco de dados desse processo.
A arquitetura em três camadas pode parecer igual a arquitetura em duas camadas,
mas ao retirar do servidor de dados regras de negócios e de segurança, deixa-se o servidor
menos sobrecarregado, pois fica responsável por gerenciar apenas os dados.
2.2.3.4. Arquitetura Distribuída
Um BDD (Banco de Dados Distribuído) é um conjunto de banco de dados
distribuídos por uma rede de computadores, mas logicamente inter-relacionados, enquanto
o SGBDD (Sistema Gerenciador de Banco de dados Distribuído) não apenas gerencia o
BDD, mas também torna a distribuição e transações transparentes para o usuário.
Existem dois tipos de banco de dados distribuídos, os (i) homogêneos que são
compostos por um único tipo de banco de dados e os (ii) heterogêneos que são compostos
por mais de um tipo de banco de dados.

16
Num banco de dados distribuído, os dados podem estar replicados ou fragmentados.
Na replicação, é criada uma cópia de cada dado em bases diferentes, deixando as bases com
os dados iguais. Na fragmentação, os dados são divididos entre bases diferentes.
2.2.3.4.1. Vantagens
Alguns dos motivos que levaram ao desenvolvimento dessa arquitetura foram a (i)
descentralização dos dados, aumentando o poder computacional de processamento; a (ii)
fragmentação dos dados levando em consideração a estrutura organizacional, persistindo os
dados no local desejado (Ex.: Departamento de Compras) aumentando a autonomia local; a
(iii) melhoria no desempenho devido a proximidade dos dados, paralelismo e
balanceamento entre os servidores de dados; (iv) tolerância a falhas aumentando a
disponibilidade dos dados; (v) economia na aquisição de servidores menores a medida que
o poder computacional exigido for aumentado; (vi) facilidade de acrescentar ou remover
novos servidores.
2.2.3.4.2. Desvantagens
O uso do banco de dados distribuído não só tem vantagens, mas traz consigo
algumas desvantagens como (i) complexidade exigida para garantir a distribuição de forma
transparente para o usuário; (ii) custo maior de implementação devido ao trabalho extra
exigido; (iii) planejamento mais difícil devido a fragmentação, alocação e, algumas vezes, a
replicação dos dados; (iv) integridade do banco exige alto recurso de rede; (v) exigência de
maior segurança tanto nos servidores quanto na infra-estrutura; (vi) inexistência de um
padrão que auxilie a conversão dos bancos de dados centralizados para os banco de dados
distribuídos; (vii) poucos casos práticos disponíveis para serem analisados.
2.2.3.4.3. Fragmentação de Dados
O tipo de fragmentação de banco de dados é a fragmentação de uma relação inteira,
ou seja, os dados de uma tabela inteira são colocados num único servidor do BDD. Dessa
maneira sempre que se precisar de alguma informação da tabela, o SGBDD irá busca essa
informação no servidor que a mantém. Para exemplificar suponha que um BDD tenha cinco
servidores de dados e que as tabelas do BDD estão espalhadas como mostrado na
tabela 2.1.

17
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Servidor Tabela # Registros
S01 Cliente 10000
S02 Fornecedor 1000
S03 PDV 1000000
S04 PDV_Item 4000000
S05 Estoque 10000
Neste exemplo o servidor S02 vai precisar de um poder computacional bem menor
que o servidor S04 para atender as solicitações feitas, uma vez que o número de registros do
servidor S02 é bem menor que do servidor S04, causando um desbalanceamento de carga
entre os servidores.
Na fragmentação horizontal, as tuplas (registros) são divididas horizontalmente
entre os vários servidores. Esse tipo de fragmentação diminui o problema do
desbalanceamento de carga entre os servidores como pode ser visto na tabela 2.2. Com a
fragmentação horizontal cada registro da tabela fica em um servidor, junto com todos os
seus atributos (colunas).
Tabela 2.2 – Exemplo de fragmentação horizontal
Tabela: Cliente
Servidor ID_Cliente ome_Cliente Cidade_Cliente
S01 1 Roberto Juazeiro do Norte
S02 2 Helena Fortaleza
S03 3 Francisco Crato
S01 4 Lucas Barbalha
S02 5 Ylane Juazeiro do Norte
S03 6 Eduardo Barbalha
S01 7 Carlos Fortaleza
S02 8 Vitor Fortaleza
S03 9 Maria Crato

18
A fragmentação vertical divide as tuplas e seus atributos (tabela 2.3), o problema
nesse tipo de fragmentação está na obrigatoriedade de incluir a chave primária ou chave
candidata em cada parte da fragmentação, para que esses valores possam ser resgatados e
unidos quando necessário.
Existe ainda a possibilidade de combinar a fragmentação horizontal com a
fragmentação vertical gerando uma fragmentação mista ou híbrida.
2.2.3.4.4. Replicação de Dados
A replicação ou redundância de dados é usada para melhorar a disponibilidade dos
dados, pois através dela obtém-se um sistema de alta disponibilidade, mantendo o sistema
sempre disponível, mesmo em casos de falhas de componentes ou sobrecargas do sistema.
Embora a replicação de dados melhore a disponibilidade e o desempenho do banco
de dados, a mesma reduz a velocidade das operações de atualização, uma vez que cada
atualização deverá ser replicada em todas as cópias existentes para manter a consistência
dos dados redundantes.
Tabela 2.3 – Exemplo de fragmentação vertical
Tabela: Cliente
Servidor ID_Cliente ome_Cliente Servidor ID_Cliente Cidade_Cliente
S01 1 Roberto S04 1 Juazeiro do Norte
S02 2 Helena S05 2 Fortaleza
S03 3 Francisco S06 3 Crato
S01 4 Lucas S05 4 Barbalha
S02 5 Ylane S04 5 Juazeiro do Norte
S03 6 Eduardo S06 6 Barbalha
S01 7 Carlos S06 7 Fortaleza
S02 8 Vitor S04 8 Fortaleza
S03 9 Maria S05 9 Crato

19
2.2.4. SQL
A SQL (Structured Query Language – Linguagem Estruturada de Consulta)
permitiu padronizar a construção e acesso a SGBDR (Sistema de Gerenciamento de Bancos
de Dados Relacional) de diferentes tipos e em diferentes plataformas de software e
hardware.
Essa padronização impulsionou não apenas a disseminação dos SGBDR, mas
também a própria SQL. Para entender a importância da SQL são mostrados nesta subseção
todos os pontos que levaram os DBAs (Database Administrator – Administrador de Banco
de Dados) a ter na SQL um aliado importante.
No final da década de 1960 o matemático Edgar Frank Codd apresentou as
primeiras idéias sobre banco de dados relacional. Em junho de 1970 publicou o artigo “A
relational model of data for large shared data banks – Um modelo relacional de dados para
grandes bancos de dados compartilhados”, o que lhe rendeu em 1981 o prêmio ACM
TURING AWARD2.1
.
Em 1973 a IBM criou o seu primeiro gerenciador de dados relacional, o SYSTEM R
que utilizava a linguagem de consulta SEQUEL (Structured English Query Language –
Linguagem Inglesa Estruturada de Consulta). Por motivos legais, a sigla foi alterada para
SQL, mas o primeiro SGBDR disponível comercialmente foi o ORACLE em 1979.
A primeira versão padronizada da SQL ocorreu em 1986, ficando conhecida como
SQL-86. Esse padrão foi inicialmente desenvolvido no âmbito da ANSI (American
ational Standards Institute – Instituto Nacional Americano de Padrões) sendo aprovado
pela ISO (International Organization for Standardization – Organização Internacional para
Padronização) em 1987.
Em 1989 foi publicada uma extensão do padrão SQL-86 chamada de SQL-89. A
SQL-92, também chamada de SQL2, foi publicado em 1992 e aprovado pela ISO. Essa
versão da SQL foi dividida tem três partes:
1. Entry Level (Nível de Entrada) – Nesse nível foi definido um conjunto
mínimo de comando para ser considerado padrão SQL
2. Intermediate level (Nível Intermediário)
2.1
O prêmio ACM TURING AWARD é conferido a uma pessoa que tenha dado contribuições de natureza
técnica a comunidade computacional

20
3. Full (Completo)
A SQL-99 ou SQL3 foi aprovado pela ISO no final de 1999. Nela foi definido o
uso de triggers, stored procedures, consultas recursivas entre outros. Esse padrão também
definiu regras para os SGBDOR (Sistema de Gerenciamento de Bancos de Dados Objeto-
Relacional), implementando assim o suporte ao tratamento de objetos. No ano de 2003 foi
lançado o SQL-2003, introduzindo características relacionadas ao XML, seqüências
padronizadas e colunas com valores de auto-generalização.
A SQL é uma linguagem padronizada, mas cada SGBDR apresenta dialeto próprio,
com extensões diferentes entre cada fabricante de SGBD.
Os comandos da SQL são separados em grupos:
• DDL (Data Definition Language – Linguagem de Definição de Dados):
Subconjunto utilizado para criar, alterar e excluir tabelas e elementos
associados; esse é o grupo que mais muda de um fabricante para outro.
• DCL (Data Control Language – Linguagem de Controle de Dados):
Subconjunto de comandos que controla o acesso dos usuários aos dados.
• DTL (Data Transaction Language - Linguagem de Transação de Dados):
Subconjuntos de comandos usados para iniciar e finalizar transações.
• DML (Data Manipulation Language – Linguagem de Manipulação de
Dados): Subconjunto dos comandos usado para inserir, atualizar e apagar
dados.
• DQL (Data Query Language – Linguagem de Consulta de Dados): Com
apenas um único comando – select – e suas várias cláusulas e opções – nem
sempre obrigatórias – permite recuperar os dados de uma ou mais tabelas
através de consultas elaboradas como uma descrição do resultado desejado.
Além desses grupos de comandos a SQL tem operadores lógicos, operadores
relacionais e funções de agregação que, assim como na DDL, pode mudar de um fabricante
para outro.
2.2.5. XML
XML (Extensible Markup Language – Linguagem de Marcação Extensiva) é uma
linguagem universal usada para troca de informações entre organizações, empresas,

21
departamentos e banco de dados – entre outros – de uma forma transparente e organizada,
permitindo ao desenvolvedor criar as marcações (tags) mais adequadas para cada situação.
O XML passou a ser recomendada como padrão pelo W3C (World Wide Web
Consortium – Consórcio da World Wide Web) depois de estudos – feito em meados da
década de 1990 – que tinham o intuito de combinar a flexibilidade do SGML2.2
(Standard
Generalized Markup Language – Linguagem Padronizada de Marcação Genérica) com a
simplicidade do HTML (HyperText Markup Language – Linguagem de Marcação de
Hipertexto).
Com a combinação do SGML com o HTML pretendia-se criar uma linguagem que
oferecesse a capacidade de leitura via software e fosse facilmente integrada com outras
linguagens. Conforme [FARIA, 2005], essa capacidade promoveu comunicação entre
fornecedores e clientes, agilizando e reduzindo custos de processos.
Essa troca de informação barrava geralmente na incompatibilidade das tecnologias
utilizadas pelos dois lados, deixando o processo mais complicado. Esse ambiente abriu as
portas para o padrão XML, que passou a ser considerada a principal maneira para realizar
intercâmbio de dados entre tecnologias distintas, uma vez que combinava dois modelos
conceituais – (i) modelos empregados nos sistemas de documento e (ii) modelos de banco
de dados.
No XML os dados são organizados usando estruturas de árvores hierárquicas, e são
representados como elementos que podem ficar aninhados, permitindo a criação de
estruturas hierárquicas complexas. A figura 2.4 mostra um exemplo de um elemento XML
complexo.
2.3. Conclusão
O conhecimento sobre computação distribuída é importante para esta dissertação,
pois ela propõe um middleware para a distribuição dos dados armazenados. Conhecido os
processos de comunicação entre os sistemas distribuídos, torna-se mais claras as estratégias
adotada no projeto do middleware proposto neste trabalho.
2.2
“SGML... foi uma linguagem criada... com o objetivo de construir um sistema portável... com o qual
pudéssemos compartilhar e processar documentos.” [FARIA, 2005]

22
Figura 2.4 – Um elemento XML complexo chamado <projetos> – Fonte: [ AVATHE, 2005]
A abordagem sobre cluster e grid computing foi incluída para que ficasses claro que
na elaboração do middleware, elas foram descartadas propositalmente e não por
desconhecimento do autor.
As arquiteturas de banco de dados contribuirão na delimitação do problema, ou seja,
o middleware foi elaborado para aumentar o desempenho de SGBDRs sobre a arquitetura
cliente-servidor de duas camadas. O aumento de desempenho foi feito utilizando
fragmentação horizontal dos dados.
A SQL é fundamental a dissertação, uma vez que o middleware trabalha com
SGBDRs. Já o conhecimento de XML é importante, uma vez que o middleware utiliza
desse padrão para gerar as respostas das consultas feitas pelo sistema cliente.

23
Capítulo 3
Trabalhos Relacionados
Neste capítulo é apresentada uma visão geral sobre as soluções adotadas pelos
SGBDs Oracle 10g e PostgreSQL para fornecer suporte a distribuição dos dados, com o
intuito de fornecer alta disponibilidade, tolerância a falhas, replicação, balanceamento de
carga, alto desempenho e escalabilidade. Também é apresentado o middleware Sequoia e
um modelo para o compartilhamento de bases de dados distribuídas.
3.1. Oracle 10g
O Oracle 10g foi o primeiro banco de dados destinado a grid computing. Melhorias
foram implementadas e lançadas na versão do Oracle 11g, contudo a estrutura básica do
Oracle 10g foi mantida.
No Oracle 10g, o banco de dados se acomoda no grid computing através da
clusterização de servidores, do armazenamento auto-gerenciado e dos mecanismos de auto-
gerenciamento e auto-ajuste. Nesse cenário, a inclusão de novos recursos ou exclusão de
recursos existentes pode ser feito sem a necessidade de parar o banco de dados e seus
aplicativos.
“Esta arquitetura baseia-se em servidores de custo relativamente baixo,
mas constantemente atualizados. Os servidores devem estar
interconectados em uma estrutura de cluster. O Oracle Application
Server 10g e o Oracle Database 10g foram concebidos para serem
executados em clusters e poderem alocar dinamicamente os recursos de
acordo com a necessidade do grid.” [OLIVEIRA, 2004].
3.1.1. Real Application Cluster
O RAC (Real Application Cluster) é o principal componente do Oracle 10g, pois
através dele o Oracle 10g oferece alta disponibilidade, escalabilidade, proteção contra
falhas de hardware e software. O RAC permite que o banco de dados execute aplicações em
conjunto com servidores em cluster.

24
3.1.1.1. Arquitetura do Real Application Cluster
A arquitetura física do RAC (figura 3.1) é dividida em camadas, onde na interface
de acesso tem-se os usuários que têm acesso a rede pública; a infra-estrutura de rede
mantém duas redes com papeis bem definidos, a rede pública que estabelece a conexão com
os aplicativos clientes e a rede privada, que estabelece a conexão de alta velocidade para
garantir a troca de mensagens reservadas ao funcionamento do cluster; a camada de cluster
de servidores, que mantêm as instâncias do banco de dados, fica responsável pelo
gerenciamento da carga de trabalhado e o compartilhamento da memória; a camada de
armazenamento compartilhado que mantém os arquivos do banco de dados que são
armazenados “numa localização independente e cujos métodos de acesso configurados
permitem que os seus conteúdos sejam compartilhados, de modo concorrente.”
[NOGUEIRA, 2008].
Figura 3.1 – Arquitetura física Real Application Clusters – Fonte: [ OGUEIRA, 2008]
3.1.2. Oracle Clusterware
O RAC deve ser colocado sobre um cluster já montado. Ainda que o RAC possa
trabalhar sobre um cluster de terceiros certificado pela Oracle, ela desenvolveu o Oracle
Clusterware que é uma solução especifica para seu banco de dados.

25
O Oracle Clusterware monitora e gerencia o RAC, dessa maneira se houver uma
falha o Oracle Clusterware irá reiniciar automaticamente a instância sem que o
administrador perceba a falha. Se um novo nó for adicionado ao cluster, o Oracle
Clusterware se responsabiliza por inicializar todas as instâncias e serviços do nó
automaticamente.
3.1.3. Escalabilidade
Na arquitetura cliente-servidor de duas camadas, quando um servidor de dados está
sobrecarregado ele é substituído por outro servidor com poder computacional maior e,
conseqüentemente, mais caro.
O RAC permite planejar um crescimento gradativo e com custo menor que o de
troca de servidores. A adição de novos servidores no cluster aumenta o poder
computacional ao mesmo tempo em que não exige uma paralisação do banco de dados.
3.1.4. Pontos Fracos na Solução da Oracle 10g
Embora o RAC proporcione escalabilidade, ele só pode ser aplicado sobre uma base
de dados Oracle, mais especificamente a partir da do Oracle 10g. Outro empecilho do RAC
está na estrutura necessária que precisa ser montada para que ele possa ser executado.
3.2. PostgreSQL
Ao contrário do Oracle 10g, o PostgreSQL não implementa nativamente o grid
computing, assim como não tem recursos para gerenciamento de cluster. Contudo tem
soluções, de terceiros, projetadas para atender essas necessidades.
O PostgreSQL também não possui implementações nativas para replicação e nem
balanceamento, porem existem soluções de terceiros criadas para replicar e balancear os
dados no PostgreSQL.
3.2.1. PGCluster
O PGCluster é um sistema de replicação síncrona composto por vários servidores,
tendo como principais características o balanceamento de carga e a alta disponibilidade.
O PGCluster é composto por três tipos de máquinas:

26
• Servidor de Balanceamento (Load Balancer): Recebe consultas e as
encaminha para os nós de armazenamento. As consultas são distribuídas de
acordo com a carga de cada nó. Podem existir mais de um balanceador de
carga.
• Servidor de Armazenamento (Cluster DB): Máquina que recebe e armazena
as consultas em bancos de dados.
• Servidor de Replicação (Replicator): Cuida de manter os dados
sincronizados entre os servidores. Mais de um servidor pode ser utilizado,
neste caso, outro servidor só assume se o servidor de replicação principal
falhar.
No balanceamento de carga (figura 3.2) são combinados servidores de
armazenamento e servidores de replicação, criando um sistema em cluster. O PGCluster
distribui a carga de acesso, redirecionando consultas para máquinas com menor carga.
Figura 3.2 – Sistema de balanceamento de carga – Fonte: [GOVER OELETRO ICO, 2008]
No caso da alta disponibilidade (figura 3.3) é utilizando um servidor responsável
por distribuir a carga de acesso no cluster. Caso um servidor de armazenamento falhe o
mesmo é separado pelo servidor de replicação. Quando a falha do servidor for contornada,
ou for incluído um novo servidor, os dados são copiados para o mesmo automaticamente.

27
Figura 3.3 – Sistema de alta disponibilidade – Fonte: [GOVER OELETRO ICO, 2008]
3.2.2. PGPool
O PGPool é uma solução que fica numa camada entre o cliente e servidor de dados
com a finalidade de prover alta disponibilidade, replicação e balanceamento de carga.
“Como sistema de replicação de dados, PGPool permite backup em
tempo real de bancos de dados, enviando as mesmas declarações SQL
para ambos os servidores, podendo ser considerado um sistema de
replicação síncrona... Se algum problema torna um dos servidores
PostgreSQL indisponível, o PGPool tenta continuar o serviço com o
servidor ainda ativo.” [GOVER OELETRO ICO, 2008].
As consultas são distribuídas de maneira aleatória entre os nós para obter um ganho
de desempenho, balanceando a carga entre esses nós. Utilizando o PGPool como
middleware os aplicativos que utilizam o PostgreSQL não precisam ser modificados. Já o
número de conexões com o PostgreSQL pode ser configuráveis.
O PGPool-II é uma evolução do PGPool, que suporta até 128 nós, com poder de
processamento paralelo nos nós.
3.2.3. Slony-I
O Slony-I é um sistema de replicação que segue o modelo Master to Multiple Slaves
apoiado no cascateamento de slaves e failover. Com essa estrutura é possível garantir que
um Slave assuma a posição de Master caso um Master venha a falhar.
O Slony-I também se responsabiliza em usar rotas alternativas sempre que um Slave
responsável pela transmissão dos dados falhe. O tipo de replicação de banco de dados
adotado pelo Slony-I foi a replicação assíncrona em cascata (figura 3.4).

28
Figura 3.4 – Replicação em Cascata – Fonte: [SLO Y, Introducing, 2008]
Segundo [SLONY, 2008], Slony-I é um sistema replicador Master-Slave que inclui
todos os recursos e capacidades necessárias para replicar grandes bancos de dados para um
número razoavelmente limitado de sistemas Slaves. O Slony-I foi projetado para ser usado
em data centers e sites de backup.
No caso de falha de um Slave que fornece dados para outros Slaves, os Slaves
podem continuar a replicação através de outro Slave ou diretamente para o Master. No caso
do Master falhar (figura 3.5), um Slave pode receber uma promoção para se tornar um
Master, os outros Slaves passam a replicar o novo Master. O modelo assíncrono, adotado
pelo Slony-I, mantém réplicas em estados diferentes – mais ou menos atualizadas – por este
motivo, quando um Slave se torna um Master, ele próprio sincroniza com o estado mais
recente entre os Slaves ativos.
Figura 3.5 – Replicação continua após uma falha – Fonte: [SLO Y, Introducing, 2008]

29
3.2.4. ParGRES
O ParGRES é um middleware projetado com o objetivo de ser capaz de processar
consultas pesadas com grandes quantidades de dados. Porém para que ele possa ser
utilizado o PostgreSQL deve estar sobre um cluster de PCs. O processamento da consulta
usa o paralelismo intra-consultas3.1
e inter-consultas3.2
.
O ParGRES consiste em uma camada intermediária de software que gerencia
instâncias de SGBDs executados em diferentes nós de um cluster, implementando técnicas
de processamento paralelo. Segundo [MATTOSO, 2009] “seus componentes se encontram
distribuídos entre os nós do cluster”. Dessa maneira o ParGRES possui uma arquitetura
descentralizada como mostrado na figura 3.6.
Figura 3.6 – Arquitetura do ParGRES – Fonte: [MATTOSO, 2009]
“ParGRES está sendo desenvolvido em Java, e os testes estão sendo
executados em um cluster de PCs seguindo arquitetura de memória
distribuída. Pela sua arquitetura, o ParGRES não necessita em absoluto
de hardware específico de clusters... a implementação atual do
ParGRES está sendo utilizado o SGBD PostgreSQL versão 8.0 em cada
3.1
“Significa decompor consultas complexas em sub-consultas que serão executadas em paralelo, cada sub-
consulta em um fragmento de dados diferente. Dessa forma, cada sub-consulta poderá então ser enviada para
o nó que possui o respectivo fragmento dos dados. Assim, cada sub-consulta é enviada para um nó diferente e
executada em paralelo com as demais” [MATTOSO, 2009].
3.2
“Consultas distintas são executadas de forma concorrente no cluster de banco de dados, uma em cada nó do
cluster” [MATTOSO, 2009].

30
nó do cluster. A comunicação entre o ParGRES e cada nó do cluster é
realizada através de JDBC.” [MATTOSO, 2009].
3.2.4.1. Arquitetura
Na arquitetura do ParGRES existem componentes globais e locais. As tarefas que
envolvem vários nós do cluster são executadas pelos componentes globais, enquanto as
tarefas que são realizadas em apenas um nó são executadas pelos componentes locais.
Os componentes locais são os NQP ( ode Query Processor – Processador de
Consultas de Nó) e o PostgreSQL, enquanto os componentes globais são o Intermediador e
o CQP (Cluster Query Processor – Processador de Consultas de Cluster).
O Intermediador repassa as requisições das aplicações para o CQP, e do CQP para
as aplicações. Dessa maneira o Intermediador provê maior flexibilidade na alocação física
do CQP, aumentando o grau de tolerância a falhas do ParGRES.
3.2.4.2. Cluster Query Processor
O CQP é o componente mais importante do ParGRES, ele age como gerenciador
dos outros componentes, sendo responsável por controlar a execução de requisições do
ParGRES.
As informações presentes no Catálogo do ParGRES são utilizadas pelo CQP para
analisar as consultas e definir que tipo de paralelismo deverá ser usado. O Catálogo
armazena informações necessárias para a fragmentação virtual adaptativa, não precisando
de informações específicas do SGBD.
3.2.5. Pontos Fracos nas Soluções do PostgreSQL
As soluções do PostgreSQL têm como foco a replicação dos dados. Nenhuma das
soluções trata a escalabilidade como foco primordial. Em alguns a escalabilidade é tratada
como um problema secundário. Em outros nem isso é apresentado. Além disso, todas são
soluções direcionadas ao PostgreSQL.
3.3. Modelo para o Compartilhamento de Bases de Dados Distribuídas
e Heterogêneas
No seu trabalho apresentado por [JUNIOR, 2005] é proposto um modelo para
viabilizar o “Compartilhamento de Bases de Dados Distribuídas e Heterogêneas”

31
A figura 3.7 mostra a arquitetura do middleware proposto. Ele é formado por
artefatos denominados Agentes, que desempenham a função de relacionar-se com o
aplicativo e de relacionar-se com os outros Agentes.
O Agente utiliza socket para comunicar-se com outros Agentes. O reconhecimento
de outros Agentes e seus serviços é feito através do Diretório de Agentes.
Os Agentes Servidores se registram no Catálogo de Serviços, esse catálogo informa
aos Agentes Clientes os Agentes Servidores disponíveis e seus endereços, esse catálogo não
é persistido.
Após a identificação dos Agentes Servidores, o Agente Cliente passa a interagir
diretamente com os mesmos, não precisando mais do auxilio do Mediador.
O Agente de Gerenciamento tem a função de (i) permitir a manutenção do Diretório
de Agentes e (ii) proporcionar a situação de atividade dos Agentes em seus Catálogos de
Serviços ativos e Log de Transação gerado pelos Agentes.
Figura 3.7 – Arquitetura do modelo de mediador proposto por Tercilio Junior – Fonte: [JU IOR, 2005]
3.3.1. Atores
Os atores são definidos por [JUNIOR, 2005] da seguinte maneira:
• Agente Cliente – Aplicativo: Sistema ou software que faz o tratamento de
informações das bases de dados através do Agente Cliente.

32
• Agente Servidor – Base de Dados: Qualquer fonte de informação disponível
em ambiente computacional ou em interfaces. Os Agentes Servidores podem
ser criados para tratar informações de sistemas de arquivos, banco de dados,
informações de estado de sistemas operacionais, sensores, etc.
• Administrador do Sistema: Usa o Agente de Gerenciamento para inserir
novos agentes no Diretório de Agente e fazer o acompanhamento do
funcionamento dos serviços através do Log de Transação e da atividade dos
agentes através do Catálogo de Serviços.
3.3.2. Classes
A descrição das classes do middleware, assim como suas características e
funcionalidade é apresentado resumidamente na seqüência:
• Diretório de Agentes: Classe de entidade persistente responsável por
catalogar todos os Agentes e seus serviços, podendo ser replicado para vários
pontos da sub-rede.
• Catálogo de Serviços: Classe de entidade não persistente responsável por
catalogar os serviços ativos, sendo utilizado pelos Agentes Servidor para
poder registrar os serviços e pelos Agentes Cliente para identificar os
Agentes Servidor em atividade.
• Log de Transações: Classe de entidade persistente responsável por registrar
as atividades dos agentes, permitindo o acesso do Agente de Gerenciamento
para fornecer dados ao Administrador do Sistema.
• Agente de Gerenciamento: Classe de fronteira que consente a manutenção
do Diretório de Agentes, apresentando o estado dos serviços do Catálogo de
Agentes e Log de Transações.
• Agente Cliente: Componente do serviço de solicitação, sendo parte
integrante do aplicativo e suprindo este aplicativo com dados por meio do
mediador.
• Agente Servidor: Componente do serviço responsável por responder as
solicitações do Agente Cliente, interagindo com uma base de dados para
disponibilizar os serviços da mesma.

33
3.3.3. Pontos Fracos do Middleware
A implementação do middleware proposto em [JUNIOR, 2005] se caracterizou por
Independência de Ambiente Operacional (Portabilidade), Independência física de dados,
Transparência de Localização, Redundância dos Serviços e Gerenciamento do Ambiente.
Mas na proposta, [JUNIOR, 2005] não apresenta uma estrutura para distribuição e
balanceamento de dados, de forma transparente ao sistema cliente.
3.4. Sequoia
O Sequoia é um middleware de código aberto desenvolvido para deixar
transparente, a aplicativos JAVA, o acesso a um cluster de banco de dados pelo meio do
JDBC (Java Database Connectivity). Com esse middleware os aplicativos clientes,
aplicativos servidores e servidores de banco de dados não sofrem alterações, bastando o
Sequoia ter acesso aos bancos de dados.
O uso do Sequoia necessita de uma aplicação cliente que utilize o JDBC, uma JVM (Java
Virtual Machine – Máquina Virtual Java) compilada para JDK (Java Development Kit – Kit
de Desenvolvimento Java) 1.4 ou superior, um banco de dados com driver JDBC ou ODBC
(Open Data Base Connectivity – Conectividade com Base de Dados Aberta), comunicação
entre o nós do cluster via TCP/IP.
3.4.1. Arquitetura
A arquitetura flexível provida pelo Sequoia permite escalabilidade, alta
disponibilidade e tolerância a falhas por meio do conceito de RAIDb (Redundant Array of
Inexpensive Databases – Conjunto Redundante de Base de Dados Econômicos), onde o
banco de dados é distribuído e replicado entre diversos nós, ficando o Sequoia responsável
por distribuir a carga das consultas entre eles.
3.4.2. RAIDb
O RAIDb é o equivalente do RAID (Redundant Array of Inexpensive Drives –
Conjunto Redundante de Discos Econômicos) só que no contexto de banco de dados. No
RAID vários discos rígidos são combinados em um array, obtendo melhor desempenho,
capacidade e confiabilidade. Já o RAIDb propõe obter melhor desempenho e tolerância a
falhas combinando várias instâncias de banco de dados em um array de banco de dados.

34
3.4.2.1. RAIDb-0
Nesse nível do RAIDb (figura 3.8) os dados são particionados, distribuindo suas
tabelas entre as máquinas que hospedam o banco de dados. Tabelas diferentes podem estar
em nós distintos, mas uma mesma tabela não pode estar em mais de um nó. O RAIDb-0
particiona o banco de dados, mas a tolerância a falha não é oferecida.
Figura 3.8 – Exemplo de RAIDb-0 – Fonte: [GOVER OELETRO ICO, 2008]
3.4.2.2. RAIDb-1
Nesse nível de RAIDb (figura 3.9) é disponibilizado o espelhamento integral,
replicando totalmente os dados entre as máquinas que hospedam o banco de dados,
permitindo total tolerância a falhas. A escrita no banco de dados – update, insert, delete –
se torna mais onerosa, pois as requisições devem ser enviadas para todos os nós.

35
3.4.2.3. RAIDb-2
A combinação de RAIDb-0 com RAIDb-1 cria o RAIDb-2 (figura 3.10). Nesse
nível o RAIDb provê replicação parcial, melhorando o desempenho em comparação ao
RAIDb-1. Cada tabela tem que estar em pelo menos dois nós, mas é necessário no mínimo
quatro nós para este nível de RAIDb.
3.4.2.4. Aninhamento de RAIDb
A utilização de vários níveis de RAIDb simultaneamente é possível. Com apenas
um controlador RAIDb é possível escala um número limitado de bancos de dados, mas
pode-se usar vários controladores em cascata para disponibilizar, teoricamente, um número
ilimitado de banco de dados.
No RAIDb-1-0 (figura 3.11) um controlador RAIDb-1 fica no nível mais alto,
enquanto no RAIDb-0-1 (figura 3.12) o nível mais alto fica um controlador RAIDb-0.
3.4.3. Pontos Fracos do Sequoia
O Sequoia proporciona escalabilidade, alta disponibilidade e tolerância a falhas,
mas só é possível ser usado por aplicativos JAVA.
Embora seja um consenso, entre os profissionais da área de programação, que o
JAVA estar entre as linguagens mais populares, uma quantidade grande de aplicativos não
pode usufruir do Sequoia, pois foram desenvolvidos em outras linguagens.

36
3.5. Conclusão
Embora o Oracle e o PostgreSQL apresentem soluções para resolver o problema de
escalabilidade, todas elas são para banco de dados homogêneos. O middleware proposto
nesta dissertação foi construído para resolver o problema de escalabilidade em banco de
dados heterogêneos.
Figura 3.11 – Exemplo de RAIDb-1-0 – Fonte: [GOVER OELETRO ICO, 2008]
Figura 3.12 – Exemplo de RAIDb-0-1 – Fonte: [GOVER OELETRO ICO, 2008]
A proposta apresentada em [JUNIOR, 2005] não aborda a distribuição e
balanceamento dos dados de maneira transparente ao sistema cliente. O seu trabalho ficou
limitado a uma solução para o compartilhamento de bases de dados distribuídas e

37
heterogêneas. O middleware apresentado nesta dissertação vai mais além da proposta de
[JUNIOR, 2005]. Além do compartilhamento de dados distribuídos em bases heterogêneas,
também apresenta uma solução para a distribuição e balanceamento de dados heterogêneos.
Na solução do Sequoia foi levado em consideração apenas aplicativos
desenvolvidos em JAVA. No middleware proposto nesta dissertação, a heterogeneidade da
linguagem de programação é tão importante quanto a heterogeneidade dos dados
armazenados.

38
Capítulo 4
O Middleware LUCAS-GABRIEL
Este capítulo apresenta o middleware proposto nesta dissertação, o qual foi
denominado LUCAS-GABRIEL. Ele tem a finalidade de aumentar a escalabilidade
associada a independência dos SGBDRs com arquitetura cliente-servidor de duas camadas.
O LUCAS-GABRIEL distribui os dados entre os SGBDRs, gerenciando o
balanceamento entre os mesmos. Depois, quando recebe solicitações de atualização de
dados, o LUCAS-GABRIEL redireciona a solicitação de maneira correta aos SGBDRs.
Também é de responsabilidade do LUCAS-GABRIEL receber as solicitações de consulta,
redirecionar aos SGBDRs, consolidar os resultados dos SGBDRs e enviar a consolidação
para sistema que solicitou a consulta.
4.1. Introdução
A arquitetura do LUCAS-GABRIEL é mostrada na figura 4.1, nesta arquitetura os
dados são distribui horizontal (Leia 2.2.3.4.3. Fragmentação de Dados) entre SGBDRs. O
LUCAS-GABRIEL não irá interferir diretamente no funcionamento dos SGBDRs.
O software cliente se comunica com o módulo LUCAS (Lançador Uniforme de
Consultas Acessado por Software), que é uma classe encapsulada dentro de uma DLL, com
isso, a máquina onde está o software fica livre de qualquer tipo de instalação cliente de
SGBD.
Numa camada intermediária fica o módulo GABRIEL (Gerenciador de Acesso a
Banco Receptor de Invocações Enviadas do LUCAS). Esta camada é responsável por
distribuir horizontalmente os dados entre os SGBDs registrados.
O GABRIEL recebe as solicitações de modificação de estados dos dados emitidas
pelo software cliente via LUCAS. Na seqüência, o GABRIEL processa e distribui as
solicitações entre os servidores balanceando a carga entre os mesmos.
O GABRIEL também se responsabiliza pelo gerenciamento das solicitações de
dados, repassando as mesmas para os servidores, em seguida, faz a consolidação das
respostas e as envia para o software cliente via LUCAS.

39
Figura 4.1 – Middleware proposto
Esta arquitetura deixa o gerenciamento dos dados mais complexo, porém, em
contra-partida ganha nas consulta de dados, uma vez que os mesmos são processados em
locais distintos. Outra vantagem da arquitetura é a heterogeneidade dos SGBDRs e a
possibilidade de inclusão de novos servidores para aumentar a escalabilidade.
4.2. Diagrama de caso de uso
O middleware é dividido em duas partes, o LUCAS e o GABRIEL (figura 4.2). O
LUCAS fica do lado cliente, isto quer dizer que cada cliente deve ter o LUCAS instalado
localmente. Entre o LUCAS e os SGBDs tem-se o GABRIEL, que é o núcleo do
middleware. O middleware não terá nada instalado do lado do SGBDR, para o SGBDR o
GABRIEL é um cliente.
A figura 4.3 ilustra o diagrama da figura 4.2 mais detalhadamente. Na figura 4.3 são
apresentados os casos de uso básicos, nesta figura é possível ver que todo serviço existente
no LUCAS precisa, para sua conclusão, de um outro serviço que está no GABRIEL.
GABRIEL
Servidor
Firebird
Memória
Servidor
PostgreSQL
Memória
Servidor
MySQL
Memória
Cliente Cliente Cliente Cliente Cliente
LUCAS LUCAS LUCAS LUCAS LUCAS

40
Figura 4.2 – Diagrama de caso de uso sintético
Figura 4.3 – Diagrama de caso de uso básico
Os diagramas de caso de uso não são aprofundados, pois a usabilidade do
middleware será detalhada no transcorrer deste capítulo.
A troca de mensagens entre LUCAS e GABRIEL é realizada via socket. Nas
consultas de dados, o GABRIEL consolida os dados num arquivo XML e envia ao LUCAS
via socket. A escolha do socket foi devido a simplicidade das mensagens e dos dados
trocados. Já o XML foi escolhido devido já ser um padrão amplamente usado e conhecido.
Um exemplo de um arquivo XML gerado pelo GABRIEL e enviado ao LUCAS pode ser
visto na figura 4.4.

41
Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware
O esquema do arquivo XML gerado está diretamente relacionado com o metadado
da origem dos dados, mas três tags são comuns a todos os arquivos XML gerados:
• <?xml version="1.0" encoding="ISO-8859-1"?>
Esta tag especial define a versão do documento XML através do
atributo version, enquanto o atributo encoding define a tabela
caracteres que será usada no arquivo. Esta tag deve aparecer apenas
uma vez no arquivo XML
• <dados>
Local onde os registros ficam armazenados. Esta tag deve aparecer
apenas uma vez no arquivo XML.
• <registro>
Define uma tupla e os valores armazenados em seus atributos. Esta
tag pode aparecer uma vez, várias vezes ou nenhuma vez no arquivo
XML, o que define a quantidade de vezes é o resultado gerado pela
consulta.
Ainda analisando o exemplo apresentado na figura 4.4 tem-se as tags < OME>,
<E DER>, <BAIRRO>, <CEP>, <CIDADE> e <UF> dentro da tag <registro>. Os
<?xml version="1.0" encoding="ISO-8859-1"?>
<dados>
<registro>
<NOME>SAULA SAMPAIO BRINGEL IZIDORO</NOME>
<ENDER>RUA PADRE CICERO</ENDER>
<BAIRRO>MATRIZ</BAIRRO>
<CEP>63.000.000</CEP>
<CIDADE>JUAZEIRO DO NORTE</CIDADE>
<UF>CE</UF>
</registro>
<registro>
<NOME>TADEU PEREIRA LIMA FRANCA</NOME>
<ENDER>RUA PADRE CICERO</ENDER>
<BAIRRO>MATRIZ</BAIRRO>
<CEP>63.000.000</CEP>
<CIDADE>JUAZEIRO DO NORTE</CIDADE>
<UF>CE</UF>
</registro>
</dados>

42
nomes destas tags são iguais aos nomes dos atributos da tupla retornada pela consulta, e no
seu conteúdo estão os valores dos atributos da tupla.
4.3. Diagrama de classe
Nesta seção é apresentado o diagrama de classes do middleware, além do
detalhamento dos seus atributos e métodos.
4.3.1. LUCAS
A figura 4.5(a) apresenta o LUCAS detalhado em um diagrama de classe, nesta
figura é possível ver todos os atributos e métodos da classe.
Figura 4.5(a) – Diagrama de classe do LUCAS
Detalhamento da classe LUCAS
Na figura 4.5(b) pode-se ver o relacionamento do LUCAS com a classe
ClientSocket, o tipo enumerado Tipo_Solicitacao e as exceções que podem ser geradas. Na
mesma figura também pode-se ver detalhada a classe ClientSocket e o relacionamento da
mesma com o tipo enumerado Tipo_Status.

43
Figura 4.5(b) – Diagrama de classe do LUCAS
Detalhamento da (i) classe ClientSocket, do (ii) tipo enumerado Tipo_Solicitacao e
das (iii) exceções e como os mesmos se relacionam com a classe LUCAS
A classe ClientSocket é responsável por abrir a conexão, via socket, com a classe
ServerSocket e envia solicitações à mesma.
O detalhamento dos atributos e métodos do LUCAS pode ser visto nas tabelas do
Apêndice A. Os atributos e métodos da classe ClientSocket, da qual o atributo
SoqueteCliente do LUCAS descende, estão nas tabelas do Apêndice B.
Existem sete exceções criadas pelo LUCAS. A exceção ExceptionAguardando
acontece quando o Status do atributo SoqueteCliente está diferente de zero (Aguardando), a
exceção ExceptionBaixando acontece quando existe uma falha na transferência do arquivo
de retorno da consulta. As exceções ExceptionIncluindo, ExceptionAlterando,
ExceptionExcluindo e ExceptionConsultando são executadas quando um dos SGBDRs
retornarem um erro, neste caso a mensagem é repassada do SGBDR para o sistema cliente.
A última exceção é a ExceptionMensagem que acontece sempre que um erro não esperado
ocorrer no GABRIEL.

44
4.3.2. GABRIEL
Na figura 4.6(a) o diagrama de classe do GABRIEL é apresentado. Na figura 4.6(b)
pode-se ver o relacionamento do GABRIEL com as classes ServerSocket e SQLConnect.
Figura 4.6(a) – Diagrama de classe do GABRIEL
Detalhamento da classe GABRIEL
Figura 4.6(b) – Diagrama de classe do GABRIEL
Detalhamento das classes (i) ServerSocket e (ii) SQLConnect e
como as mesmas se relacionam com a classe GABRIEL

45
A classe ServerSocket é responsável por gerenciar as conexões e solicitações
enviadas pela classe ClientSocket, enquanto a classe SQLConnect gerencia a conexão e as
transações feitas ao SGBDR.
Pode-se ver nas tabelas do Apêndice C o detalhamento dos atributos e métodos do
GABRIEL. Nas tabelas do Apêndice D tem-se o equivalente para a classe ServerSocket,
enquanto as tabelas do Apêndice E se referem a classe SQLConnect.
4.4. Diagrama de seqüência
Os diagramas de seqüências da inclusão, alteração, exclusão e consultas são
apresentados nesta seção.
4.4.1. Incluir
4.4.1.1. Incluir registro independente
As figuras 4.7(a) à 4.7(f) mostram o diagrama de seqüência para incluir um registro
numa tabela sem chave estrangeira. O digrama foi desmembrado em sete partes para
permitir a visualizar.
No caso de uma inclusão independente o Sistema Cliente deve invocar os métodos
Clear e SetTabela da classe LUCAS, em seguida, para cada campo e valor que se deseja
incluir no novo registro o método SetDados deve ser invocado.
Para entender melhor, imagine que se deseja incluir um registro na tabela Cliente
com os dados da tabela 4.1.
Tabela 4.1 – Incluir registro independente
Tabela: Cliente
Campo Valor
Nome José da Silva
Endereco Rua Todos os Santos
Cidade Juazeiro do Norte
UF CE
O Sistema Cliente deve executar o código semelhante ao mostrado:

46
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetDados(‘Nome’, ‘José da Silva’);
LUCAS.SetDados(‘Endereco’, ‘Rua Todos os Santos’);
LUCAS.SetDados(‘Cidade’, ‘Juazeiro do Norte’);
LUCAS.SetDados(‘UF’, ‘CE’);
LUCAS.SetIncluir(True);
O comando SQL gerado pelo método SetRequisitar (Leia Apêndice F) do LUCAS e
enviado ao GABRIEL fica como mostrado:
insert into Cliente (Nome, Endereco, Cidade, UF)
values (‘José da Silva’, ‘Rua Todos os Santos’,
‘Juazeiro do Norte’, ‘CE’);
Quando recebe a solicitação, o GABRIEL, por meio do seu atributo ServidorTabela,
seleciona o servidor que tem menos registro na tabela informada. Por fim, redireciona o
comando para o servidor escolhido. Logo, o balanceamento entre os SGBDs são garantidos
pelo GABRIEL através do atributo ServidorTabela.
Figura 4.7(a) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS

47
Figura 4.7(b) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes LUCAS e ClientSocket
Figura 4.7(c) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes ClientSocket e ServerSocket

48
Figura 4.7(d) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes ServerSocket e GABRIEL
Figura 4.7(e) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes GABRIEL e SQLConnect
Figura 4.7(f) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre a classe SQLConnect e os SGBDs

49
4.4.1.2. Incluir registro dependente
A inclusão de um registro que possua chave estrangeira, e onde esta chave
estrangeira deve ser igual a chave primária de uma inclusão anterior, mas ainda
desconhecida, deve seguir o diagrama de seqüência mostrado nas figuras 4.8(a) e 4.8(b), a
partir do ClientSocket o diagrama de seqüência é semelhante ao mostrado nas figuras 4.7(c)
à 4.7(f).
Figura 4.8(a) – Diagrama de Seqüência – Incluir registro dependente

50
Figura 4.8(b) – Diagrama de Seqüência – Incluir registro dependente
Mensagens trocadas entre as classes LUCAS e ClientSocket
Uma venda via pedido é um cenário onde se inclui registros dependentes. A chave
primária do pedido é chave estrangeira para seus itens, mas a chave primária só será
conhecida no momento da inclusão.

51
O desconhecimento da chave primária do pedido pode causar inconsistência nos
dados, uma vez que se forem incluídos dois ou mais pedidos num mesmo instante, não tem
como saber qual a chave primária que os itens lançados nesses pedidos distintos devem
obter, uma vez que um pedido pode ser persistido (i) antes de todos, (ii) após todos ou (iii)
entre lançamentos.
Para simplificar, é mostrado como incluir dados em casos semelhantes, conforme
tabela 4.2.
Tabela 4.2 – Incluir registro dependente
Tabela: Pedido
Campo Valor
DtPedido 01/01/2009
ID_Vend 10
ID_Cliente 153
Tabela: Pedido_Item
Campo Valor
ID_Pedido ???????
ID_Produto 1234567890
Quant 2
Tabela: Pedido_Item
Campo Valor
ID_Pedido ???????
ID_Produto 0987654321
Quant 5
O código que deve ser executado pelo Sistema Cliente fica semelhante ao mostrado:
LUCAS.Clear;
LUCAS.SetTabela(‘Pedido’);
LUCAS.SetDados(‘DtPedido’, ‘01/01/2009’);
LUCAS.SetDados(‘ID_Vend’, ‘10’);
LUCAS.SetDados(‘ID_Cliente’, ‘153’);

52
LUCAS.SetIncluir(False);
LUCAS.SetTabela(‘Pedido_Item');
LUCAS.SetChaveEstrangeira(‘Pedido’, 'ID_Pedido');
LUCAS.SetDados(‘ID_Produto’, ‘1234567890’);
LUCAS.SetDados(‘Quant’, ‘2’);
LUCAS.SetDados(‘ID_Produto’, ‘0987654321’);
LUCAS.SetDados(‘Quant’, ‘5’);
LUCAS.SetRequisitar;
Note que só foi preciso configurar o nome da tabela e a chave estrangeira
(SetTabela e SetChaveEstrangeira) no primeiro item. Uma vez que o parâmetro do método
SetIncluir do LUCAS recebeu o valor falso, o mesmo se encarrega de configurar estes
valores (SetTabela e SetChaveEstrangeira) automaticamente, ficando por conta do Sistema
Cliente informar apenas os campos e seus valores através do método SetDados.
O comando gerado pelo método SetRequisitar (Leia Apêndice F) do LUCAS e
enviado ao GABRIEL fica igual ao mostrado a seguir:
insert into Pedido (DtPedido, ID_Vend, ID_Cliente)
values (‘01/01/2009’, ‘10’, ‘153’);
insert into Pedido_Item (ID_Produto, Quant)
values (‘1234567890’, ‘2’), ‘Pedido’, ‘ID_Pedido’;
insert into Pedido_Item (ID_Produto, Quant)
values (‘0987654321’, ‘5’), ‘Pedido’, ‘ID_Pedido’;
Ao receber esta solicitação de inclusão, o GABRIEL executa o processo a seguir:
Pedido.Gerador_ID := Pedido.Gerador_ID + 1;
insert into Pedido (ID, DtPedido, ID_Vend, ID_Cliente)
values (Pedido.Gerador_ID, ‘01/01/2009’, ‘10’, ‘153’);
insert into Pedido_Item (ID_Pedido, ID_Produto, Quant)

53
values (Pedido.Gerador_ID, ‘1234567890’, ‘2’);
insert into Pedido_Item (ID_Pedido, ID_Produto, Quant)
values (Pedido.Gerador_ID, ‘0987654321’, ‘5’);
A figura 4.9 mostra o fluxograma para inclusão de dados.
Figura 4.9 – Fluxograma para inclusão de dados
4.4.2. Alterar
A alteração de dados se assemelha com a inclusão de dados. A diferença básica está
no tocante ao método SetChaveEstrangeira, que neste caso é desprezado pelo método
SetRequisitar, uma vez que, em uma alteração, a chave estrangeira já é conhecida.
O algoritmo usado pelo GABRIEL replica a solicitação enviada pelo LUCAS em
todos os servidores. A desvantagem dessa escolha é a perda de desempenho da rede, pois a
mesma solicitação é enviada ao vários servidores. A vantagem é o ganho de desempenho
dos servidores, devido cada servidor ter que processar uma quantidade menor de dados.
O diagrama de seqüência da alteração de dados é mostrado na figura 4.10, a
continuação desse diagrama é semelhante ao mostrado nas figuras 4.7(b) à 4.7(f).
Não Sim
Não Sim
NãoSim
Inicio
SetTabela
[SetChaveEstrangeira]
SetDados
Novos
Dados
SetIncluir
Requisitar
Fim
SetRequisitar
Nova
Tabela
Clear

54
Figura 4.10 – Diagrama de Seqüência – Alterar registro
Tendo como base os dados da tabela 4.3, é mostrado a seguir como o Sistema
Cliente deve efetuar a alteração neste registro.
Tabela 4.3 – Alterar registro
Tabela: Cliente
Campo Valor Atual ovo Valor
ID 150
Nome José da Silva
Endereco Rua Todos os Santos Rua Padre Cícero
Cidade Juazeiro do Norte
UF CE
O código que deverá ser executado:
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetDados(‘Endereco’, ‘Rua Padre Cicero’);
LUCAS.SetAlterar(‘ID = 150’, True);
O comando SQL gerado (Leia Apêndice F):
update Cliente

Middleware Clusters SGBDs

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Middleware Clusters SGBDs

Ähnlich wie Middleware Clusters SGBDs (20)

Middleware Clusters SGBDs