Dissertação (56)

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.

“Co 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.

“Ca 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. Ceste 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 Cetwork – Rede de Área Local) ou

WAN (Wide Area Cetwork – 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.

Cormalmente, 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.” [CAVATHE,

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

Cational 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.” [GOVERCOELETROCICO, 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... Ca 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 (Code 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 <COME>,

<ECDER>, <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


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ão Sim

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.SetDados(‘Endereco’, ‘Rua Padre Cicero’);

LUCAS.SetAlterar(‘ID = 150’, True);

O comando SQL gerado (Leia Apêndice F):

update Cliente

55

set Endereço = ‘Rua Padre Cicero’

where ID = 150;

O fluxograma para alteração de dados é mostrado na figura 4.11.

Figura 4.11 – Fluxograma para alteração de dados

4.4.3. Excluir

O processo de excluir dados é o mais simples, pois neste caso são usados apenas os

métodos Clear, SetTabela e SetExcluir, os métodos SetDados e SetChaveEstrangeira são

desprezados. A figura 4.12 mostra o diagrama de seqüência da exclusão de dados até o

LUCAS, a partir do LUCAS o diagrama é semelhante ao mostrado nas figuras 4.7(b) à

4.7(f).

Figura 4.12(a) – Diagrama de Seqüência – Excluir registro


Não Sim

Não Sim

Não Sim

Inicio

SetTabela

SetDados

Novos Dados

SetAlterar

Requisitar

Fim

SetRequisitar

Nova Tabela

Clear

56

O código executado pelo Sistema Cliente deve ficar semelhante ao mostrado a

seguir:

LUCAS.Clear;


LUCAS.SetExcluir(‘ID = 150’, True);

O comando SQL gerado (Leia Apêndice F):

delete from Cliente

where ID = 150;

O algoritmo usado pelo GABRIEL para excluir dados é semelhante ao da alteração

de dados, uma vez que o GABRIEL replica a solicitação enviada pelo LUCAS em todos os

servidores. Na figura 4.13 tem-se o fluxograma para exclusão de dados.

Figura 4.13 – Fluxograma para exclusão de dados

Não Sim

Não Sim

Inicio

SetTabela

SetExcluir

Requisitar

Fim

SetRequisitar

Nova Tabela

Clear

57

4.4.4. Consultar

Para consulta existem dois caminhos possíveis, (i) usando o método SetConsultar

ou (ii) usando o método SetConsultarSQL, mas nos dois casos, o GABRIEL replica a

consulta em todos os servidores.

No primeiro caso os métodos Clear, SetTabela e SetDados são usados em conjunto

com o método SetConsultar, sendo que o método SetDados tem o seu segundo parâmetro

(Valor) desconsiderado.

Para a segunda opção todos os outros métodos são desprezados (Clear, SetTabela,

SetChaveEstrangeira, SetDados) uma vez que neste caso o Sistema Cliente deve passar o

comando de consulta já formatado de acordo com os requisitos da SQL.

Para fazer uma consulta através do método SetConsultar, o LUCAS verifica se

existem solicitações pendentes. Caso existam, ele manda para o GABRIEL todas essas

solicitações para serem atendidas, só então a solicitação de consulta é enviada. Desta

maneira LUCAS fica livre para esperar o arquivo XML de retorno, gerado no GABRIEL,

com os dados consolidados da consulta feita nos SGBDs e unificados neste arquivo.

4.4.4.1. SetConsultar

A figura 4.14 mostra o diagrama de seqüência até o LUCAS, quando o Sistema

Cliente usa o método SetConsultar. A continuação do diagrama é idêntico aos das figuras

4.7(b) à 4.7(f).

Figura 4.14 – Diagrama de Seqüência – Consultar via SetConsultar


58

O Sistema Cliente deve ficar com o código semelhante ao mostrado:

LUCAS_Clear;

LUCAS_SetTabela(‘Cliente’);

LUCAS_SetDados(‘ID’, ‘’);

LUCAS_SetDados(‘Nome’, ‘’);

LUCAS_SetDados(‘Endereco’, ‘’);

LUCAS_SetDados(‘Cidade’, ‘’);

LUCAS_SetDados(‘UF’, ‘’);

LUCAS_SetConsultar(‘ID between 100 and 1000’);

Comando SQL gerado (Leia Apêndice F):

select ID, Nome, Endereco, Cidade, UF from Cliente

where ID between 100 and 1000;

Na figura 4.15 é mostrado o fluxograma para se efetuar este mesmo procedimento.

Figura 4.15 – Fluxograma para consultar dados via SetConsultar

4.4.4.2. SetConsultarSQL

O fluxograma deste método é mais simples que o anterior, pois ele permite uma

consulta otimizada. Contudo, se o implementador do Sistema Cliente não tiver experiência

com SQL este método se torna mais difícil de ser usado. O diagrama de seqüência com

Não Sim

Inicio

Clear SetTabela

SetDados

Novos Dados

SetConsultar

Fim

SetRequisitar

59

este método está nas figuras 4.16(a) e 4.16(b). A continuação do diagrama assemelha-se aos

das figuras 4.7(c) à 4.7(f).

Figura 4.16(a) – Diagrama de Seqüência – Consultar via SetConsultarSQL


Figura 4.16(b) – Diagrama de Seqüência – Consultar via SetConsultarSQL


Código do Sistema Cliente:

SetConsultarSQL(‘select ID, Nome, Endereco, Cidade, UF ’

‘from Cliente where ID between 100 and 1000’);

Comando SQL gerado:

select ID, Nome, Endereco, Cidade, UF from Cliente

where ID between 100 and 1000;

4.5. Fluxos alternativos e Funcionalidade

As solicitações de inclusão, alteração e exclusão podem ficar pendentes no LUCAS,

bastando para isso informar como falso o parâmetro Requisitar dos métodos SetIncluir,

SetAlterar e SetExcluir.

60

Para enviar as pendências ao GABRIEL o método SetRequisitar deve ser invocado

de maneira direta ou indireta. No primeiro caso o Sistema Cliente deve incorporar no seu

código a chamada ao método SetRequisitar. No outro caso basta informar o parâmetro

Requisitar da última solicitação como verdadeiro, pois uma vez que os métodos SetIncluir,

SetAlterar e SetExcluir invocam o método SetSolicitar e, ao passar o parâmetro Requisitar

como verdadeiro, o mesmo invoca o método SetRequisitar (veja figuras 4.7, 4.10 e 4.12),

todas a pendências do LUCAS são enviadas para o GABRIEL.

O método SetChaveEstrangeira só é utilizado pelo LUCAS em conjunto com o

método SetIncluir. Nos outros métodos (SetAlterar, SetExcluir e SetConsultar) ele é

desprezado.

O segundo parâmetro do método SetDados (Valor) não é utilizado quando o método

é usado em conjunto com o método SetConsultar.

O método SetRequisitar processa todas as solicitações pendentes e as repassa para o

método EnviarMensagem. Em seguida invoca o método Clear para apagar todas as

solicitações enviadas.

4.6. Conclusão

Neste capítulo foi apresentado o middleware LUCAS-GABRIEL. Este middleware

propõe uma arquitetura de armazenamento de dados distribuído para SGBDRs com

arquitetura cliente-servidor de duas camadas. Com essa distribuição, o LUCAS-GABRIEL

aumenta a escalabilidade dos SGBDRs com arquitetura cliente-servidor de duas camadas.

O LUCAS-GABRIEL efetua a distribuição horizontal dos dados entre instâncias

distintas de SGBDRs, mas sem interferir diretamente sobre o processamento dos SGBDRs.

Ele atua numa camada intermediária entre o sistema cliente e os SGBDRs. Com esta

camada intermediária o processo de comunicação entre o sistema cliente e SGBDR muda.

Este novo processo é mostrado na seqüência:

1. O sistema cliente manda a solicitação ao LUCAS (Lançador Uniforme de

Consultas Acessado por Software);

2. O LUCAS recebe as solicitações do sistema cliente, organiza estas

solicitações e as envias ao GABRIEL (Gerenciador de Acesso a Banco

Receptor de Invocações Enviadas do LUCAS);

61

3. O GABRIEL recebe as solicitações e processa as mesmas, agindo de

maneira distinta para cada tipo de solicitação:

a. Inclusão: É feita a distribuição de maneira a manter os SGBDRs

balanceados.

b. Alterações/Exclusões: A solicitação é replicada entre os SGBDRs

para que a solicitação seja executada.

c. Consultas: A solicitação é repassada para os SGBDRs, o retorno da

consulta é consolidado num arquivo XML.

4. O Gabriel envia uma resposta ao LUCAS;

5. O LUCAS repassa a resposta ao sistema cliente.

Desta maneira o sistema cliente não se comunica diretamente com o SGBDR,

apenas através do LUCAS-GABRIEL. Em contrapartida, o LUCAS-GABRIEL deixa

transparente ao sistema cliente a estrutura física dos dados persistidos. Também é possível

incluir novas instâncias de SGBDRs na estrutura computacional sem que o sistema cliente

perceba tal ação.

62

Capítulo 5

Validação

Para testar a arquitetura proposta foi efetuada a implementação do

LUCAS-GABRIEL, além de programa auxiliares. As implementações foram feitas no

Delphi 5.0.

Embora a proposta do LUCAS-GABRIEL seja independência de SGBD, os testes

foram feitos apenas com o Firebird 2.0 instanciado em todos os servidores. Esta

homogeneidade de SGBD na validação permite apresentar resultados mais confiáveis de

desempenho.

Já o sistema operacional usado foi o Windows XP Professional Service Pack 3

rodando em hardwares com configurações idênticas. Assim como no SGBD, este ambiente

de hardware e software homogêneo proporcionou uma validação mais confiável.

Neste capítulo é descrito o ambiente de teste e casos para validação da arquitetura.

5.1. DLL “LUCAS”

A classe LUCAS foi criada seguindo todas as normas da arquitetura proposta. Nesta

primeira versão, a classe foi incorporada numa DLL (LUCAS.DLL) que passou a

disponibilizar os métodos do objeto LUCAS_DLL – instância da classe LUCAS – através

de chamada a DLL.

A escolha por criar a DLL, nesta versão, foi a opção que melhor se encaixou na

reutilização da classe por qualquer linguagem de programação que tenha suporte ao uso de

DLL. Embora muitas linguagens de programação tenham suporte ao uso de DLL, ficou

para estudos futuros a busca de uma solução que deixe o LUCAS ainda mais heterogêneo

quanto a linguagem de programação do sistema cliente.

A tabela G.1 do Apêndice G mostra os métodos disponibilizados e como efetuar sua

chamada via DLL.

5.2. Aplicativo “GABRIEL”

Foi criado um aplicativo responsável por instanciar a classe GABRIEL, o aplicativo

acessa os métodos da instância do GABRIEL. Os servidores configurados ficam visíveis

63

constantemente. As tabelas, seus campos chaves, seus geradores e valores dos mesmos são

atualizados constantemente. A figura 5.1 mostra o aplicativo GABRIEL em execução.

Figura 5.1 – Aplicativo GABRIEL

5.3. Aplicativo “Cliente”

O aplicativo Cliente simula um sistema cliente com a função de incluir, alterar,

excluir ou consultar registros nas tabelas, mas quando informada a tabela “PDV” para

inclusão, o aplicativo insere registros nas tabelas “PDV” e “PDV_Item”. As ações de

incluir, alterar, excluir ou consultar podem ser feitas diretamente no SGBD ou através do

GABRIEL.

Neste aplicativo é instanciado um objeto do tipo ServerSocket para servir de elo de

comunicação entre ele o aplicativo Configura Cliente (Leia 5.4. Aplicativo Configura

Cliente). Quando o objeto do tipo ServerSocket do aplicativo Cliente recebe uma

mensagem do aplicativo Configura Cliente é iniciado o processo de configuração da DLL

“LUCAS” e sincronizada a hora do computador local com a do computador onde está o

aplicativo Cliente.

64

Figura 5.2 – Aplicativo Cliente

A tabela G.2 do Apêndice G mostra os métodos criados para auxiliar a sobrecarga.

5.4. Aplicativo “Configura Cliente”

A tabela a ser usada, ação a ser efetuada, período inicial e quantidade de vezes que a

ação será executada são configurados através deste aplicativo (figura 5.3). O aplicativo

Configura Cliente também informa se as ações acontecerão (i) diretamente no SGBD, para

verificar o desempenho do SGBD sem uso do LUCAS-GABRIEL, ou (ii) através do

GABRIEL, para verificar o desempenho dos SGBDs gerenciados pelo GABRIEL. Este

aplicativo também tem uma instância de um objeto do tipo ClientSocket, através do qual

são enviadas as configurações para as instâncias do aplicativo Cliente que serão utilizadas

no caso de validação. Os itens da interface do aplicativo são explicados na seqüência. As

caixas de edições são usadas para configurar tanto dados individuais das instâncias do

aplicativo Cliente quanto dados comuns a todas as instâncias do aplicativo Cliente.

5.5. Cenário

As CPUs usados nos testes eram iguais devido serem de um mesmo lote de compra

(tabela G.3 do Apêndice G). Foram utilizados dezessete CPUs, das quais seis ampararam as

instâncias do Firebird 2.0 e o GABRIEL. As outras onze mantiveram o aplicativo Cliente

divididas da seguinte maneira:

‒ Quatro CPUs efetuavam mil ações sobre a tabela Cliente;

‒ Uma CPU efetuava mil ações sobre a tabela Funcion;

‒ Uma CPU efetuava mil ações sobre a tabela Produto;

‒ Cinco CPUs efetuavam mil ações sobre a tabela PDV.

65

As ações dependiam do processo que estava sendo executado durante o caso de

validação.

Figura 5.3 – Aplicativo Configura Cliente

5.6. Casos de Validação

A validação foi feita através de três processos distintos descritos na seqüência:

1. Incluir Dados: Todos os aplicativos que usavam o LUCAS efetuavam

inclusões de dados.

2. Alterar Dados: Todos os aplicativos que usavam o LUCAS efetuavam

alterações de dados.

3. Consultar Dados: Todos os aplicativos que usavam o LUCAS efetuavam

consultas de dados.

Cada processo passou por seis casos de validações com as seguintes características:

‒ Caso de Validação 1: Neste caso de validação os aplicativos de Cliente não

usaram o GABRIEL, a sobrecarga foi feita em um único SGBD.

‒ Caso de Validação 2: Neste caso de validação os aplicativos de Cliente

usaram o GABRIEL, mas o GABRIEL estava gerenciando o acesso a apenas

um único SGBD.


usaram o GABRIEL gerenciando o acesso a dois SGBDs.

66


usaram o GABRIEL gerenciando o acesso a três SGBDs.


usaram o GABRIEL gerenciando o acesso a quatro SGBDs.


usaram o GABRIEL gerenciando o acesso a cinco SGBDs.

O processo de “Incluir Dados” foi executado em todos os casos de validação

descritos, ou seja, do “Caso de Validação 1” até o “Caso de Validação 6”. Em seguida foi

executado o processo de “Alterar Dados” da mesma maneira, e assim sucessivamente.

Deste modo todos os processos de “Incluir Dados” foram executados em um momento

cronológico anterior aos processos subseqüentes.

No “Caso de Validação 1” o servidor S1 manteve o SGBD na arquitetura Cliente-

Servidor tradicional, ou seja, com os dados centralizados em um único servidor de dados. O

GABRIEL não estava instanciado e os servidores S2, S3, S4, S5, S6 não entram no teste.

No “Caso de Validação 2” o servidor S1 manteve a instância do GABRIEL,

enquanto o servidor S2 mantinha uma instância do SGBD. Os servidores S3, S4, S5, S6 não

entram no teste.

No “Caso de Validação 3” o servidor S1 manteve a instância do GABRIEL,

enquanto os servidores S2 e S3 mantinham instâncias do SGBD, uma instância para cada

servidor. Os servidores S4, S5, S6 não entram no teste.

Para cada novo caso de validação, um novo servidor se unia aos servidores S2 e S3.

Os resultados apresentados nas próximas subseções tiveram como referencia o valor

relativo do servidor S1 no “Caso de Validação 1”, logo os valores percentuais estão

diretamente proporcionais ao mesmo. Desta maneira, o caso de validação que apresentar

valor acima de 100% implica em desempenho pior que o “Caso de Validação 1”.

Conseqüentemente, sempre que o valor estiver abaixo de 100% implica em desempenho

melhor que o “Caso de Validação 1”.

5.6.1. Incluir Dados

Neste processo as bases de dados, de cada caso de validação, estavam inicialmente

limpas. A tabela 5.1 mostra os resultados percentuais médio de desempenho da CPU.

67

Na coluna Servidor desta tabela são mostrados os servidores. Na coluna Caso 1 é

apresentado o resultado do servidor S1 no “Caso de Validação 1”. O valor apresentado

para o servidor S1 no “Caso de Validação 1” é tomado com referencia para os servidores

ativos nos casos de validações posteriores.

A coluna Caso 2 apresenta os resultados dos servidores S1 e S2 no “Caso de

Validação 1”. A coluna Caso 3 apresenta o resultados dos servidores S1, S2 e S3 no “Caso

de Validação 3”. As outras colunas têm suas explicações semelhantes as já apresentadas.

A figura 5.4 mostra o gráfico de desempenho das CPUs baseado na tabela 5.1.

Tabela 5.1 – Percentual médio de desempenho da CPU no processo de inclusão de dados

Servidor Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6 S1 100% 122% 94% 83% 72% 72% S2

28% 11%

6% 6%

6% S3

S4

S5

S6

A tabela 5.2 mostra os resultados percentuais médio da utilização da rede, sua

explicação é análoga a da tabela 5.1. A figura 5.5 mostra o gráfico de desempenho da rede

fundamentado na tabela 5.2.

Tabela 5.2 – Percentual médio da utilização da rede no processo de inclusão de dados


74% 33%

20% 18%

13% S3

S4

S5

S6

68

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

A tabela 5.3 mostra como as tabelas dos SGBDRs ficaram povoadas após as

inclusões. Na coluna Servidor foram colocados os servidores. Na coluna Tabela foram

colocas as tabelas que estavam em cada servidor. Todos os servidores continham as

mesmas tabelas.

Na coluna Caso 1 é apresentado o total de registros em cada tabela do servidor S1

após a conclusão do “Caso de Validação 1”. O mesmo acontece na coluna Caso 2 onde é

69

mostrado o total de registros nas tabelas do servidor S2 após a conclusão do “Caso de

Validação 2”.

A coluna Caso 3 apresenta o total de registros nas tabelas dos servidores S2 e S3

após o “Caso de Validação 3”. As colunas Caso 4, Caso 5 e Caso 6 mostram o equivalente

dos “Caso de Validação 4” à “Caso de Validação 6”.

Tabela 5.3 – Tabelas dos SGBDRs após o processo de inclusão de dados

Servidor Tabela Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6

S1

Cliente 4000

Funcion 1000

PDV 5000 PDV_Item 15000

Produto 1000

S2

Cliente

4000 2000 1334 1000 800 Funcion 1000 500 334 250 200

PDV 5000 2500 1666 1250 1000 PDV_Item 15000 7500 5000 3750 3000

Produto 1000 500 333 250 200

S3

Cliente

2000 1333 1000 800 Funcion 500 333 250 200

PDV 2500 1667 1250 1000 PDV_Item 7500 5000 3750 3000

Produto 500 334 250 200

S4

Cliente

1333 1000 800 Funcion 333 250 200

PDV 1667 1250 1000 PDV_Item 5000 3750 3000

Produto 333 250 200

S5

Cliente

1000 800 Funcion 250 200

PDV 1250 1000 PDV_Item 3750 3000

Produto 250 200

S6

Cliente

800 Funcion 200

PDV 1000 PDV_Item 3000

Produto 200

70

5.6.2. Alterar Dados

Neste processo as bases de dados, de cada caso de validação, estavam com os dados

incluídos nos processos de inclusão de dados dos seus respectivos caso de validação. A

tabela 5.4 e a figura 5.6 mostram os resultados percentuais médio de desempenho da CPU,

enquanto a tabela 5.5 e a figura 5.7 mostram os resultados percentuais médio da utilização

da rede.

As explicações para as tabelas 5.4 e 5.5 são análogas as das tabelas 5.1 e 5.2,

respectivamente.

Tabela 5.4 – Percentual médio de desempenho da CPU no processo de alteração de dados


25% 25%

25% 13%

13% S3

S4

S5

S6

Figura 5.6 – Gráfico do percentual médio de desempenho da CPU na alteração de dados

71

Tabela 5.5 – Percentual médio da utilização da rede no processo de alteração de dados


37% 37%

37% 37%

37% S3

S4

S5

S6

Figura 5.7 – Gráfico do percentual médio da utilização da rede na alteração de dados

5.6.3. Consultar Dados

Neste processo as bases de dados, de cada caso de validação, estavam com os dados

alterados nos processos de alteração de dados dos seus respectivos caso de validação. A

tabela 5.6 e a figura 5.8 mostram os resultados percentuais médio de desempenho da CPU,

enquanto a tabela 5.7 e figura 5.9 mostram os resultados percentuais médio da utilização da

rede.

As explicações para as tabelas 5.6 e 5.7 também são análogas as das tabelas 5.1 e

5.2, respectivamente.

72

Tabela 5.6 – Percentual médio de desempenho da CPU no processo de consulta de dados


59% 33%

29% 15%

11% S3

S4

S5

S6

Figura 5.8 – Gráfico do percentual médio de desempenho da CPU na consulta de dados

Tabela 5.7 – Percentual médio da utilização da rede no processo de consulta de dados


117% 67%

42% 25%

17% S3

S4

S5

S6

73

Figura 5.9 – Gráfico do percentual médio da utilização da rede na consulta de dados

5.7. Análise da validação

A implementação e validação do middleware chegou aos seguintes resultados:

1. Incluir Dados: Neste processo o middleware mostrou-se parcialmente viável

quando usado no “Caso de Validação 2”, uma vez que o servidor

mantenedor do GABRIEL sofreu uma sobrecarga na CPU maior que no

“Caso de Validação 1” quando mantinha apenas o SGBD. Mas no “Caso de

Validação 2” o servidor que mantinha a instância do SGBD obteve um

ganho significativo se comparando com o caso de validação anterior. Do

“Caso de Validação 3” à “Caso de Validação 6” tanto o servidor

mantenedor do GABRIEL quanto os que mantinham o SGBD obtiveram

ganhos de uso da CPU se comparados ao “Caso de Validação 1”. A

utilização da rede por parte do servidor S1 manteve-se estável em todos os

casos de validação, quanto aos servidores S2 à S6, à medida que um novo

servidor era incluído na arquitetura, a utilização da rede obtinha ganho de

desempenho.

2. Alterar Dados: Neste processo o middleware mostrou-se parcialmente

viável, uma vez que o servidor S1 obteve desempenho pior com o uso do

GABRIEL. Já os servidores S2 à S6 sempre tiveram desempenho melhor que

74

o servidor S1 no “Caso de Validação 1”. Esta mesma situação foi verificada

no requisito utilização da rede.

3. Consultar Dados: Neste processo o servidor S1 só obteve melhor

desempenho de uso da CPU nos “Caso de Validação 5” e “Caso de

Validação 6”, em contra-partida, a cada novo servidor colocado na

arquitetura, o desempenho das CPUs foram melhoradas consideravelmente.

Os piores desempenhos da utilização da rede ocorreram neste processo, o

servidor S1 sempre obteve resultados piores quando utilizava o middleware

proposto, enquanto o servidor S2 só obteve desempenho melhor de

utilização de rede a partir do “Caso de Validação 3”, já os servidores S3 à

S6 sempre obtiveram um desempenho melhor de utilização da rede. No

“Caso de Validação 6” os servidores S2 à S6 obtiveram desempenho de

utilização de rede semelhante ao do servidor S1 quando aplicado o “Caso de

Validação 1” no processo de inclusão de dados.

5.8. Conclusão

O middleware proposto efetuou a distribuição horizontal dos dados entre os

SGBDRs instanciados, garantindo escalabilidade maior que a arquitetura cliente-servidor

de duas camadas.

Quando o LUCAS-GABRIEL foi utilizado, os servidores com as instâncias dos

SGBDRs sempre obtiveram resultados melhores, mesmo quando o servidor com a instância

do GABRIEL mostrou desempenho inferior ao valor de referencia.

Para o sistema cliente passar a usar o middleware proposto, bastou substituir os

comandos SQL pelas chamadas aos métodos da classe LUCAS via DLL. Desta maneira

softwares projetados para arquitetura cliente-servidor de duas camadas podem migrar para

uma arquitetura de escalabilidade maior com poucas alterações na sua implementação.

Para o LUCAS-GABRIEL ser utilizado não foi preciso a existência de cluster ou

grid computing. Para cada nova instância de SGBDR incluído no middleware proposto, foi

necessário apenas informar ao GABRIEL o endereço do novo banco de dados.

Estes motivos comprovam que o middleware LUCAS-GABRIEL é viável.

75

Capítulo 6

Conclusão e Trabalhos Futuros

Este capítulo apresenta comentários conclusivos sobre a dissertação. Na seqüência é

apresentada a conclusão e as dificuldades encontradas, além dos trabalhos futuros.

6.1. Síntese da Dissertação

O aumento do armazenamento de dados trouxe consigo problemas, um deles foi a

necessidade de softwares capazes de manter grandes volumes e dados seguros e

disponíveis. Técnicas de distribuição e replicação de dados foram aplicadas para garantir a

recuperação dos dados, mas tais técnicas não resolvem problemas de disponibilidade e

escalabilidade.

O banco de dados Oracle 10g impulsionou a integração de técnicas de maneira

nativa com a finalidade de fornecer alta disponibilidade, tolerância a falhas, replicação,

balanceamento de carga, alto desempenho e escalabilidade. Outro banco com estudos na

área é o PostgreSQL, mas as soluções desenvolvidas para o PostgreSQL não são

implementações nativas.

A arquitetura apresentada nesta dissertação não é direcionada a um único banco de

dados, mas para uma estrutura de armazenamento de dados homogênea ou heterogênea.

Esta arquitetura é montada sobre o middleware LUCAS-GABRIEL, o middleware se

responsabiliza em distribuir os dados horizontalmente entre os SGBDs, mas sem interferir

nos processos internos dos SGBDs.

No middleware LUCAS-GABRIEL, o sistema cliente envia suas solicitações ao

LUCAS que organiza as mesmas e as envias ao GABRIEL. O GABRIEL, por sua vez,

gerencia as solicitações junto aos SGBDRs e envia uma resposta para o LUCAS que a

repassa esta resposta para o sistema cliente.

6.2. Conclusão

Os resultados das validações demonstraram que o middleware LUCAS-GABRIEL é

viável, pois os SGBDRs sempre ganharam desempenho. O bom resultado nos SGBDRs foi

conseguido graças ao processo de distribuição dos dados executado pelo middleware.

76

As validações também demonstraram que a proposta inicial de aumentar a

escalabilidade dos SGBDRs com arquitetura cliente-servidor de duas camadas foi

alcançada.

A comunicação via socket, entre o sistema cliente e o middleware proposto,

permitiu montar uma estrutura de acesso a dados para sistemas implementados em qualquer

linguagem de programação que suporte o uso de socket.

Os requisitos que o middleware LUCAS-GABRIEL se propôs a resolver foram

conseguidos e provados na validação.

6.2.1. Vantagens do Middleware

Embora existam outras propostas de distribuição de dados (Leia Capítulo 3), o

middleware LUCAS-GABRIEL apresenta um conjunto de benefícios não igualados pelas

outras propostas estudadas:

• Heterogeneidade da linguagem de programação do sistema cliente;

• Independência de SGBDR;

• Estrutura distribuída de armazenamento de dados;

• Balanceamento dos dados armazenados entre os SGBDRs;

• Transparência na distribuição dos dados;

• Escalabilidade.

A heterogeneidade da linguagem de programação para o sistema cliente é um ponto

forte do middleware, pois beneficiar sistemas legados.

Com a independência de SGBDR, as regras de acesso ao banco de dados, mantidas

no sistema cliente, não precisam mudar quando o SGBDR for mudado.

A estrutura distribuída de armazenamento de dados aumenta o poder computacional

de processamento, melhorando o desempenho quando comparado com uma estrutura

centralizada (Leia 2.2.3.4. Arquitetura Distribuída).

O balanceamento dos dados entre os SGBDRs aumento o desempenho das

solicitações feitas pelo sistema cliente. Uma vez que cada SGBDR tem apenas parte dos

dados, o processamento das solicitações nesses dados exige um poder computacional

menor.

77

O sistema cliente não precisa ficar preocupado em gerenciar os dados distribuídos, o

middleware LUCAS-GABRIEL faz isso de maneira transparente.

Problemas de escalabilidade podem ser contornados incluindo novos servidores de

dados na estrutura gerenciada pelo middleware LUCAS-GABRIEL.

6.2.2. Limitações do Middleware

As validações apontaram que a centralização das solicitações no GABRIEL –

localizado em único nó – causou perda de desempenho do GABRIEL em situações

especifica, tanto no desempenho médio da CPU, quanto no desempenho médio da

utilização da rede.

Devido o GABRIEL não manter um esquema para o gerenciamento dos dados

armazenados junto aos SGBDRs, o uso de junções em consultas SQL se torna inviável no

middleware. A falta de esquema também impossibilitou a implementação da replicação dos

dados em um ou mais servidores de dados.

6.3. Dificuldades Encontradas

Uma pesquisa sobre o banco de dados Oracle 10g foi o passo inicial para ter em

mente a estratégia utilizada pela Oracle para resolver problemas de alta disponibilidade,

tolerância a falhas, replicação, balanceamento de carga, alto desempenho e escalabilidade.

Embora a documentação sobre o Oracle 10g seja vasta, o detalhamento técnico da sua

arquitetura não é tão fácil de encontrar.

O passo seguinte foi analisar como o PostgreSQL resolveu os mesmo problemas

citados para o Oracle 10g. Assim como no caso do Oracle 10g, a documentação também é

ampla, mas neste caso a dificuldade em localizar o detalhamento técnico de suas soluções

foi bem menor. Devido o PostgreSQL ser um banco de dados open source existem várias

soluções, mas muitas estão sem implementação; direcionando os estudos para um novo

levantamento com o intuito de saber quais soluções implementadas são mais utilizadas

pelos usuários do PostgreSQL.

Na seqüência foram pesquisadas propostas independentes de banco de dados, e

assim como no PostgreSQL, a documentação é vasta, mas a grande maioria se limitou

apenas em documentar, não levando adiante a implementação e os testes para validação.

78

Com a pesquisa feita, foi iniciado o desenho da arquitetura, tendo como foco os

diagramas de classes e de seqüências. Tais diagramas foram refinados muitas vezes até

chegar à versão apresentada neste documento.

Com os diagramas prontos foi iniciado a implementação do middleware, exigindo

maiores esforços nos tópicos de identificação do IP, criação e tratamento de mensagens e

seu envio e recebimento via sockets, além da criação, tratamento, envio e recebimento de

arquivos XML.

Por fim, foi necessário conseguir um laboratório para que os testes de validação

fossem feito, sendo necessário instalar o middleware além do Firebird 2.0, todos

instanciados sobre o sistema operacional Windows XP Professional Service Pack 3 (Leia

5.5. Cenário).

6.4. Trabalhos Futuros

Ao incorporar a classe LUCAS numa DLL, o middleware ficou heterogêneo quanto

a linguagem de programação do sistema cliente, porém limitou seu uso as linguagens de

programação que tem suporte a DLL. Deixar o LUCAS ainda mais heterogêneo deve ser

revisto em estudos futuros.

A perda de desempenho do GABRIEL é um ponto que merece ser alvo de estudos

futuros, para transformar o mesmo em um aplicativo distribuído. Estes estudos devem

tentar remover o ponto de sobrecarga detectado nos testes de validação e o ponto de falha

no caso de queda do GABRIEL.

O uso de esquemas pelo GABRIEL para gerenciar os dados e as instâncias dos

SGBDRs por si só já é uma questão que deve ser levantada para estudos futuros, mas a

criação de esquemas pode levar a outros estudos futuros como os mostrados na seqüência:

‒ Fragmentação vertical dos dados: O uso de esquemas permitiria ao

middleware evoluir para a fragmentação vertical dos dados;

‒ Alta disponibilidade dos dados: Com o uso de esquemas pode ser

implementado a redundância dos dados em instâncias distintas do SGBDs

aumentando a disponibilidade dos dados;

‒ Balanceamento automático de carga: Sempre que um novo servidor

ingressasse na arquitetura, o middleware se encarregaria de refazer o

79

balanceamento entre as instâncias do SGBDs, aumentando o desempenho do

sistema como um todo.

Um estudo futuro com esquema importante que deve ser considerado é a

fragmentação de relação inteira, onde todos os dados de uma tabela são mantidos num

único servidor. Desta maneira sistemas ERP (Enterprise Resource Planning – Sistemas

Integrados de Gestão Empresarial) e CRM (Customer Relationship Management - Gestão

de Relacionamento com o Cliente) poderiam se beneficiar do middleware, pois estes

sistemas veriam o middleware como um SGBD único, se preocupando apenas em solicitar

os serviços ao GABRIEL, implementando SOA (Service Oriented Architecture –

Arquitetura Orientada a Serviços) na arquitetura de distribuição de dados do middleware.

Independente do uso de esquema para fragmentação de dados, o middleware pode

ser usado como SOA em consultas entre empresas do mesmo grupo que retornem, por

exemplo, o histórico de compras e pagamentos de um determinado cliente, conjuntura

comum em empresas que tenham uma ou mais filiais, e que são obrigadas a utilizar

soluções nem sempre práticas (consulta via telefone entre a matriz e as filiais, troca de

mensagens instantâneas, etc.) para obter tais informações.

80

Apêndice A

Detalhamento dos atributos e métodos da classe LUCAS.

Tabela A.1 – Atributos da classe LUCAS

Atributo Conteúdo

Porta_Endereco - Porta que será usada na conexão;

- Endereço do GABRIEL;

- Endereço onde será colocado o arquivo XML retornado

pelo GABRIEL

Tabela - ID da solicitação;

- Tabela que será usada na solicitação;

- Tipo de Solicitação (tipo enumerado Tipo_Solicitacao);

- Condição (quando houver) que deve ser atendida na solicitação

ChaveEstrangeira - ID da solicitação;

- Tabela estrangeira;

- Campo da tabela local que receberá o valor da chave primária da

tabela estrangeira

Dados - ID da solicitação;

- Campo da tabela local;

- Valor que será atribuído ao campo da tabela local

ID_Solicitacao - ID de solicitação atual

SoqueteCliente - socket cliente descendente da classe ClientSocket

Tabela A.2 – Métodos da classe LUCAS

Método Parâmetro Descrição

EnviarMensagem Mensagem Envia o conteúdo do parâmetro ao

método SetMensagem do SoqueteCliente

SalvarXML NomeAtributo Persiste, em um arquivo XML, o atributo

de configuração passado

81

SetSolicitar - Solicitar

- Condicao

- Requisitar

- Configura tipo de solicitação que será

executada (ver atributo Tabela);

- Condição que deve ser atendida

(ver atributo Tabela);

- Quando verdadeiro chama o método

SetRequisitar

Método relacionado:

- SetRequisitar

- SetTabela

- SetChaveEstrangeira

Construir Construtor da classe

SetPorta Porta Configura porta de conexão com o

GABRIEL (ver atributo Porta_Endereco)

SetMediador Endereco Configura endereço do GABRIEL

(ver atributo Porta_Endereco)

SetResposta Endereco Configura endereço do arquivo XML de

retorno (ver atributo Porta_Endereco)

SetConfiguracao - Porta

- EnderecoMediador

- EnderecoResposta

- Envia o conteúdo do parâmetro ao

método SetPorta


método SetMediador


método SetResposta

SetTabela Tabela Configura tabela que será usada na

solicitação (ver atributo Tabela)

SetChaveEstrangeira - Tabela

- Campo

- Configura tabela estrangeira

(ver atributo ChaveEstrangeira)

- Configura campo da tabela local


82

SetDados - Campo

- Valor

- Configura campo da tabela local

(ver atributo Dados)

- Configura valor que será atribuído ao

campo (ver atributo Dados)

Clear Limpa todas as solicitações pendentes

ClearChaveEstrangeira Limpa todas as chaves estrangeiras das

solicitações pendentes

ClearChaveEstrangeira - Tabela

- Campo

Limpa a chave estrangeira da solicitação

atual com tabela estrangeira e campo

local iguais aos passados pelos

parâmetros

ClearDados Limpa todos os dados das solicitações

pendentes

ClearDados Campo Limpa todos os dados da solicitação

atual com campo igual ao passado pelo

parâmetro

GetPorta Captura porta de conexão com o

GABRIEL (ver atributo Porta_Endereco)

GetMediador Captura endereço do GABRIEL

(ver atributo Porta_Endereco)

GetResposta Captura endereço do arquivo XML de

retorno (ver atributo Porta_Endereco)

GetTabela Captura IDs, tabelas, tipos de

solicitações e condições das solicitações

pendentes (ver atributo Tabela)

GetChaveEstrangeira Captura IDs, tabelas estrangeiras e

campos da tabelas locais das solicitações

pendentes


83

GetDados Captura IDs, campos e valores dos dados

das solicitações pendentes

(ver atributo Dados)

GetPendente Captura o número de solicitações

pendentes

SetIncluir Requisitar Envia o parâmetro Requisitar ao método

SetSolicitar, informando que a pendência

atual se refere a uma inclusão

SetAlterar - Condicao

- Requisitar

Envia os parâmetros Condicao e

Requisitar ao método SetSolicitar,

informando que a pendência atual se

refere a uma alteração

SetExcluir - Condicao

- Requisitar

Envia os parâmetros Condicao e

Requisitar ao método SetSolicitar,

informando que a pendência atual se

refere a uma exclusão

SetConsultar - Condição Envia os parâmetros Condicao ao

método SetSolicitar, informando que a

pendência atual se refere a uma consulta

SetConsultarSQL ComandoSelect Envia o conteúdo do parâmetro (deve ser

um comando select) ao método

EnviarMensagem

SetRequisitar Gera os comandos SQL das solicitações

pendentes e os passa ao método

EnviarMensagem


- EnviarMensagem

- Clear

84

Apêndice B

Detalhamento dos atributos e métodos da classe ClientSocket.

Tabela B.1 – Atributos da classe ClientSocket

Atributo Conteúdo

Status Status atual do socket cliente (tipo enumerado Tipo_Status)

Porta Porta que será usada na conexão

Conectado Status da conexão

Tabela B.2 – Métodos da classe ClientSocket



SetStatus Status Configura o atributo Status

SetPorta Porta Configura o atributo Porta

SetConectado Conectado Configura o atributo Conectado

GetStatus Captura o atributo Status

- Aguardando = 0;

- Processando = 1;

- Baixando = 2

GetStatus Status Captura o atributo Status, além de

retorna, através do parâmetro passado

por referencia, o valor de enumeração

Tipo_Status

GetPorta Captura o atributo Porta

GetConectado Captura o atributo Conectado

SoqueteClienteLocalizar Localizador do socket servidor

SetMensagem Mensagem Envia conteúdo do parâmetro para o

socket servidor

85

GetMensagem Captura mensagem enviada pelo socket

servidor

GetErro Captura erros que possam ocorrer entre

a conexão cliente e servidor

86

Apêndice C

Detalhamento dos atributos e métodos da classe GABRIEL.

Tabela C.1 – Atributos da classe GABRIEL

Atributo Conteúdo

Porta_Relembrar - Porta que será usada na conexão;

- Flag que indica se será efetuada uma contagem de registros nas

tabelas sempre que for efetuar uma inclusão

Servidor - Nome do servidor

- Endereço do banco de dados no servidor

Tabela - Nome das tabelas que serão gerenciadas pelo GABRIEL

- Nome do campo indicado como chave primária

- Último número gerado para a chave primaria

ServidorTabela - Nome do servidor

- Nome da tabela

- Quantidade de registros da tabela no servidor

Este atributo é o responsável por manter os SGBDs balanceados,

através da quantidade de registros que uma tabela tem em cada um

dos SGBDs

SoqueteServidor - Socket servidor descendente da classe ServerSocket

ConexaoSQL - Vetor descendente da classe SQLConnect

Tabela C.2 – Métodos da classe GABRIEL


ConstruirConexaoSGBD Servidor Construtor da conexão do GABRIEL

com o SGBD

DestruirConexaoSGBD Servidor Destruidor da conexão do GABRIEL

com o SGBD

87

ExecutarSQL - Mensagem

- Origem

- Controle

- Comando(s) SQL

- Origem do solicitante

- Número controle do solicitante

Envia o(s) comando(s) SQL (insert,

update, delete, select) do parâmetro

Mensagem para o método

ExecutarComandoSQL do

ConexaoSQL; caso o parâmetro

Mensagem contenha uma consulta

(select), os registros de retorno do

SGBDs são colocados em um arquivo

XML, onde sua identificação é feita

através dos parâmetros Origem e

Controle

SalvarXML NomeAtributo Persiste, em um arquivo XML, o

atributo de configuração passado

SetServidorTabela Atualiza o atributo ServidorTabela

sempre que houve uma atualização nos

atributos Servidor ou Tabela

EraseServidorTabela - Nome

- Servidor

- Nome do servidor ou tabela

- Flag que indica se o nome é de um

servidor ou de uma tabela

Exclui todos os itens do atributo

ServidorTabela que coincidam com os

parâmetros passados


SetPorta Porta Configura porta de conexão

(ver atributo Porta_Relembrar)

88

SetTabelaRelembrar TabelaRelembrar Configura flag de contagem de registros


SetServidor - Nome

- Endereco

Configura atributo Servidor

(ver atributo Servidor)

Métodos relacionados:

- ConstruirConexaoSGBD

- SetServidorTabela

SetConfiguracao - Porta

- ServidorNome

- ServidorEndereco

- TabelaRelembrar


método SetPorta

- Envia o conteúdo dos parâmetros ao

método SetServidor


método SetTabelaRelembrar

SetTabela - Tabela

- Chave

- Gerador

Configura atributo Tabela

(ver atributo Tabela)

Método Relacionado:

- SetServidorTabela

EraseServidor Nome Exclui o item do atributo Servidor que

coincide com o parâmetro

Métodos relacionados:

- DestruirConexaoSGBD

- EraseServidorTabela

89

EraseTabela Tabela Exclui o item do atributo Tabela que

coincide com o parâmetro


- EraseServidorTabela

GetPorta Captura porta de conexão


GetTabelaRelembrar Captura flag de contagem de registros


GetServidor Captura atributo Servidor

(ver atributo Servidor)

GetTabela Captura atributo Tabela

(ver atributo Tabela)

90

Apêndice D

Detalhamento dos atributos e métodos da classe ServerSocket.

Tabela D.1 – Atributos da classe ServerSocket

Atributo Conteúdo

Porta Porta que será usada na conexão

Conectado Status da conexão

Tabela D.2 – Métodos da classe ServerSocket



SetPorta Porta Configura o atributo Porta

SetConectado Conectado Configura o atributo Conectado

GetPorta Captura o atributo Porta

GetConectado Captura o atributo Conectado

SetMensagem Mensagem Envia conteúdo do parâmetro para o

socket cliente

GetMensagem Captura mensagem enviada pelo socket

cliente

GetErro Captura erros que possam ocorrer entre a

conexão cliente e servidor

91

Apêndice E

Detalhamento dos atributos e métodos da classe SQLConnect.

Tabela E.1 – Atributos da classe SQLConnect

Atributo Conteúdo

BaseDados Endereço da base de dados

DialetoSQL Dialeto SQL usado pelo SGBD

SolicitarLogin* Flag usado para informar se deverá ser pedido usuário e senha toda

vez que o banco de dados for conectado

Usuario* Usuário que está se conectando com o banco de dados

Senha* Senha do usuário

Ativo Status da conexão

ComandoSQL Comando SQL que deverá ser executado

*Os atributos Usuario e Senha só serão usados no momento da conexão com o SGBD se o atributo SolicitarLogin não estiver habilitado.

Tabela E.2 – Métodos da classe SQLConnect



SetBaseDados BaseDados Configura o atributo BaseDados

SetDialetoSQL DialetoSQL Configura o atributo DialetoSQL

SetSolicitarLogin SolicitarLogin Configura o atributo SolicitarLogin

SetUsuario Usuario Configura o atributo Usuario

SetSenha Senha Configura o atributo Senha

SetAtivo Ativo Configura o atributo Ativo

SetComandoSQL ComandoSQL Configura o atributo ComandoSQL

GetBaseDados Captura o atributo BaseDados

GetDialetoSQL Captura o atributo DialetoSQL

GetSolicitarLogin Captura o atributo SolicitarLogin

GetUsuario Captura o atributo Usuário

GetSenha Captura o atributo Senha

92

GetAtivo Captura o atributo Ativo

GetComandoSQL Captura o atributo ComandoSQL

ExecutarComandoSQL Executa o comando SQL que está no

atributo ComandoSQL retornando,

quando for uma consulta (select), os

registros

93

Apêndice F

Algoritmo do método SetRequisitar da classe LUCAS:

// Tabela, Dados, ChaveEstrangeira: Atributos da classe LUCAS // do tipo HashMAP. Variáveis Locais SQL: String; ReqDados: String; ReqDadosValor: String; ReqChaveEstrangeira: String; Inicio SQL.Limpar; Tabela.Primeiro; Enquanto (não for o fim de Tabela) Faça Inicio // Preparação do atributo Dados para todas as solicitações ReqDados.Limpar; Dados.Filtro = “ID_Solicitacao = ” + Tabela[“ID_Solicitacao”]; Dados.Primeiro; // Solicitação de inclusão Se (Tabela[“Solicitacao”] == “Incluir”) Então Inicio ReqDadosValor.Limpar; Enquanto (não for o fim de Dados) Faça Inicio Se (ReqDados <> “”) Então Inicio ReqDados = ReqDados + “, ”; ReqDadosValor = ReqDadosValor + “, ”; Fim; ReqDados = ReqDados + Dados[“Campo”]; ReqDadosValor = ReqDadosValor + “'” + Dados[“Valor”] + “'”; Dados.Próximo; Fim; ReqChaveEstrangeira.Limpar; ChaveEstrangeira.Filtro = “ID_Solicitacao = ” + Tabela[“ID_Solicitacao”]; ChaveEstrangeira.Primeiro; Enquanto (não for o fim de ChaveEstrangeira) Faça Inicio ReqChaveEstrangeira = ReqChaveEstrangeira + ChaveEstrangeira[“Tabela”] + “, ” + ChaveEstrangeira[“Campo”] + Char(27) + Char(10) + Char(13); ChaveEstrangeira.Próximo; Fim; Se ( ReqChaveEstrangeira <> “” ) Então Inicio ReqChaveEstrangeira = Char(27) + Char(10) + Char(13) + ReqChaveEstrangeira;

94

Fim; Se (ReqDados <> “” ) E (ReqDadosValor <> “”) Então Inicio SQL = SQL + “insert into ” + Tabela[“Tabela”] + “ (” + ReqDados + “) values (” + ReqDadosValor + “)” + ReqChaveEstrangeira + “;”; Fim; Fim SeNão Se (Tabela[“Solicitacao”] == “Alterar” ) Então Inicio Enquanto (não for o fim de Dados) Faça Inicio Se (ReqDados <> “”) Então Inicio ReqDados = ReqDados + “, ”; Fim; ReqDados = ReqDados + Dados[“Campo”] + “ = '” + Dados[“Valor”] + “'”; Dados.Próximo; Fim; Se (ReqDados <> “”) Então Inicio SQL = SQL + “update ” + Tabela[“Tabela”] + “ set ” + ReqDados + “ where ” + Tabela[“Condicao”] + “;”; Fim; Fim SeNão Se (Tabela[“Solicitacao”] == “Excluir” ) Então Inicio SQL = SQL + “delete from ” + Tabela[“Tabela”] + “ where ” + Tabela[“Condicao”] + “;”; Fim SeNão Se (Tabela[“Solicitacao”] == “Consultar” ) Então Inicio Enquanto (não for o fim de Dados) Faça Inicio Se (ReqDados <> “”) Então Inicio ReqDados = ReqDados + “, ”; Fim; ReqDados = ReqDados + Dados[“Campo”]; Dados.Próximo; Fim; Se (ReqDados <> “”) Então Inicio SQL := SQL + “select ” + ReqDados + “ from ” + Tabela[“Tabela”] + “ where ” + Tabela[“Condicao”] + “;”; Fim; Fim; Tabela.Próximo; end; EnviarMensagem(SQL); Fim;

95

Apêndice G

Tabela G.1 – Chamadas aos métodos da classe LUCAS

Método da classe LUCAS Chama via DLL

LUCAS_DLL.SetAtivarSoquete LUCAS_SetAtivarSoquete

LUCAS_DLL.SetPorta LUCAS_SetPorta

LUCAS_DLL.SetMediador LUCAS_SetMediador

LUCAS_DLL.SetResposta LUCAS_SetResposta

LUCAS_DLL.SetConfiguracao LUCAS_SetConfiguracao

LUCAS_DLL.SetTabela LUCAS_SetTabela

LUCAS_DLL.SetChaveEstrangeira LUCAS_SetChaveEstrangeira

LUCAS_DLL.SetDados LUCAS_SetDados

LUCAS_DLL.Clear LUCAS_Clear

LUCAS_DLL.ClearChaveEstrangeira LUCAS_ClearChaveEstrangeiraTudo

LUCAS_DLL.ClearChaveEstrangeira LUCAS_ClearChaveEstrangeira

LUCAS_DLL.ClearDados LUCAS_ClearDadosTudo

LUCAS_DLL.ClearDados LUCAS_ClearDados

LUCAS_DLL.GetSoqueteAtivo LUCAS_GetSoqueteAtivo

LUCAS_DLL.GetSoqueteAtivar LUCAS_GetSoqueteAtivar

LUCAS_DLL.GetPorta LUCAS_GetPorta

LUCAS_DLL.GetMediador LUCAS_GetMediador

LUCAS_DLL.GetResposta LUCAS_GetResposta

LUCAS_DLL.GetTabela LUCAS_GetTabela

LUCAS_DLL.GetChaveEstrangeira LUCAS_GetChaveEstrangeira

LUCAS_DLL.GetDados LUCAS_GetDados

LUCAS_DLL.GetPendente LUCAS_GetPendente

LUCAS_DLL.GetStatus LUCAS_GetStatus

LUCAS_DLL.GetStatus LUCAS_GetStatusDescr

LUCAS_DLL.SetIncluir LUCAS_SetIncluir

LUCAS_DLL.SetAlterar LUCAS_SetAlterar

96

LUCAS_DLL.SetExcluir LUCAS_SetExcluir

LUCAS_DLL.SetConsultar LUCAS_SetConsultar

LUCAS_DLL.SetConsultarSQL LUCAS_SetConsultarSQL

LUCAS_DLL.SetRequisitar LUCAS_SetRequisitar

Tabela G.2 – Métodos auxiliares utilizados na sobrecarga

Método Descrição Tabela

GerarNome Cria um conjunto de nomes e sobrenomes para

as inclusões

- Cliente

- Funcion

GerarEnder Cria endereços para as inclusões e alterações - Cliente

- Funcion

GerarBairro Cria bairros para as inclusões, alterações e

consultas

- Cliente

- Funcion

GerarDescr Cria descrições para as inclusões e consultas - Produto

GerarValor Cria valores monetários para as inclusões,

alterações e consultas

- Produto

GerarComiss Cria valores em percentuais para as inclusões e

consultas

- Produto

GerarPDV_ID Captura o valor que será usado no campo ID das

inclusões

- PDV

MaiorID(Tabela: string) Captura o maior valor já incluído no campo ID - Cliente

- Funcion

- Produto

- PDV

- PDV_Item

97

Tabela G.3 – Resumo das configurações dos computadores usados no teste

Sistema Operacional Windows XP Professional Service Pack 3 (build 2600) Processador 3,00 gigahertz Intel Pentium D

16 kilobyte primary memory cache 2048 kilobyte secondary memory cache 64-bit ready Multi-core (2 total) Not hyper-threaded

HD WDC WD800BB-63JKC0 [Hard drive] (80,03 GB) -- drive 0, s/n WD-WCAMDA734570, rev 05.01C05, SMART Status: Healthy

Placa Mãe Board: Gigabyte Technology Co., Ltd. VM900M Bus Clock: 200 megahertz BIOS: Award Software International, Inc. FC 08/14/2007

Memória 448 Megabytes Usable Installed Memory

98

Referências

AULT, Mike; TUMMA, Madh. Oracle 10g Grid & Real Application Clusters:

Oracle10g Grid Computing with RAC . 2004. Kittrell, North Carolina, USA: Rampant

TechPress. 680 p.

CENTER, Next Generation. Grid Computing. http://www.nextgenerationcenter.

com/v3/web/download.php?curso_id=58. 10 de Dezembro de 2008.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas

Distribuídos: Conceitos e Projetos. Tradução: João Tortello. 4. ed. Porto Alegre:

Bookman, 2007. 784 p.

FARIA, Rogério Amorim de. Treinamento Avançado em XML. São Paulo:

Digerati Books, 2005. 126 p.

FERREIRA, E. C.; SANTOS, A. F. P. dos; SCHULZE, B. Distribuição de

Processos em Ambiente de Grid. http://arquivosweb.lncc .br/pdfs/relatorio-31-03.pdf. 03

de Dezembro de 2008.

Guia de Estrutura e Administração do Ambiente de Cluster e Grid.

http://guialivre.governoeletronico.gov.br/guiaonline/downloads/guiacluster.pdf. 30 de

Dezembro de 2008.

JUNIOR, Tercilio Stedile. Um Modelo para Compartilhamento de Bases de

Dados Distribuídas e Heterogêneas. http://www.tede.ufsc.br/teses/ PGCC0679 .pdf. 13 de

Dezembro de 2008.

KUROSE, James F; ROSS, Keith W. Redes de Computadores e a Internet: Uma

abordagem top-down. Tradução: Arlete Simille Marques. 3. ed. São Paulo: Pearson

Addison Wesley, 2006. 634 p.

MATTOSO, Marta; ZIMBRÃO, Geraldo; LIMA, Alexandre A. B.; BAIÃO,

Fernanda; BRAGANHOLO, Vanessa P.; AVELEDA, Albino A.; MIRANDA, Bernardo;

ALMENTERO, Bruno Kinder; COSTA, Marcelo Nunes. ParGRES: Middleware para

Processamento Paralelo de Consultas OLAP em Clusters de Banco de Dados.

http://www.dcc.ufrj.br/~braganholo/artigos/mattoso2005-sbbd-demos.pdf. 16 de Dezembro

de 2009.

99

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 4. ed.

São Paulo, Pearson Addison Wesley, 2005. 724 p.

NOGUEIRA, Rui Miguel Silvestre Matos. Viabilidade RAC Oracle10g + Linux /

Benchmarking Linux VS Windows 2003. http://www.di.fc.ul.pt/disciplinas/pei/pei0506/

conteudo/documentos/rels_finais/0506rfinal_23052.pdf. 30 de Novembro de 2008.

OLIVEIRA, C. H. P. de. Tecnologia de Grid Computing utilizando Banco de

Dados Oracle. http://www.niee.ufrgs.br/eventos/CBCOMP/2004/mini_curso/MiniCurso

%2005.pdf. 28 de Novembro de 2008.

RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de Banco de Dados.

Tradução: Acauan Pereira Fernandes, Celia Taniwaki, João Tortello. 2. ed. São Paulo:

McGraw-Hill, 2008. 884 p.

SLONY. Slony-I. http://www.slony.info/. 30 de Dezembro de 2008.

SLONY. Introducing Slony. http://onlamp.com/pub/ a/onlamp/2004/11/18/

slony.html. 30 de Dezembro de 2008.

TANENBAUM, Andrew S. Sistemas Operacionais Modernos. Tradução: Ronaldo

A. L. Gonçalves, Luís A. Consularo. 2. ed. São Paulo: Pearson Prentice Hall, 2003. 695 p.

Dissertação (56)

Software

Transcript of Dissertação (56)