U IVERSIDADE ESTADUAL DO CEARÁ – UECE
Centro de Ciências Tecnológicas - CCT
I STITUTO FEDERAL DE EDUCAÇÃO, CIÊ CIA
E TEC O...
CICERO TADEU PEREIRA LIMA FRA ÇA
Um Middleware para o Gerenciamento de Clusters
de SGBDs Heterogêneos
Dissertação apresent...
F814m França, Cicero Tadeu Pereira Lima
Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos / Cícero Tade...
Título do trabalho: Um Middleware para o Gerenciamento de Clusters de SGBDs
Distribuídos
Autor: Cicero Tadeu Pereira Lima ...
À 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 irrestrit...
Resumo
Este trabalho apresenta um middleware para ser utilizado com SGBDRs (Sistemas
de Gerenciamento de Bancos de Dados R...
Abstract
This project shows a middleware to be used with RDBMS (Relational Database
Management System) that use the client...
Lista de Figuras
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
Figura 2.1 – A arquitetura física centralizada
...
Figura 4.13 – Fluxograma para exclusão de dados
Figura 4.14 – Diagrama de Seqüência – Consultar via SetConsultar
Figura 4....
Lista de Tabelas
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Tabela 2.2 – Exemplo de fragmentação horizont...
Lista de Abreviaturas
ANSI American National Standards Institute
API Application Program Interface
BDD Banco de Dados Dist...
SQL Structured Query Language
UML Unified Modeling Language
XML eXtensible Markup Language
W3C World Wide Web Consortium
W...
Sumário
Capítulo 1...........................................................................................................
3.2.1. PGCluster ............................................................................................................
5.6.1. Incluir Dados ........................................................................................................
1
Capítulo 1
Introdução
Nos tempos atuais a informação é um bem imprescindível. Contudo deve-se unir a
isso a necessidade ...
2
A busca e cruzamento dos dados armazenados podem gerar novas oportunidades de
negócios. Por este motivo, todo esforço fí...
3
Figura 1.1 – Arquitetura cliente-servidor de duas camadas
A falta de escalabilidade é um problema que impacta diretament...
4
a distribuição destes dados transparentes aos outros sistemas. O middleware simplificará as
solicitações, proporcionando...
5
Capítulo 2
Fundamentação Teórica
Antes de apresentar o middleware proposto, se torna necessário esclarecer alguns
concei...
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
mesm...
7
atendimento a solicitação ou, caso a mensagem seja inconsistente, retorna uma mensagem
de erro ao processo cliente.
2.1....
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 c...
9
A evolução das redes de computadores, capacitando ligar vários computadores em
uma rede e permitindo-os que desempenhem ...
10
que os serviços possam fornecê-los. Em alguns casos, são exigidas
técnicas de segurança sofisticadas para garantir o us...
11
Embora alguns middleware só suportem uma linguagem de programação,
comumente, o middleware é uma camada de software que...
12
De uma maneira simplista, um banco de dados especifica os dados, as estruturas e
as restrições enquanto o SGBD gerencia...
13
2.2.3. Arquiteturas de Banco de Dados
Assim como os modelos, no decorrer do tempo foram propostas varias arquiteturas.
...
14
“desafogando” os servidores. Os programas de interface com o usuário e os de aplicação
foram transpostos para o lado cl...
15
servidor de banco de dados. Essa camada do meio passou a chamar-se de servidor de
aplicação ou servidor Web, dependendo...
16
Num banco de dados distribuído, os dados podem estar replicados ou fragmentados.
Na replicação, é criada uma cópia de c...
17
Tabela 2.1 – Exemplo de fragmentação de uma relação inteira
Servidor Tabela # Registros
S01 Cliente 10000
S02 Fornecedo...
18
A fragmentação vertical divide as tuplas e seus atributos (tabela 2.3), o problema
nesse tipo de fragmentação está na o...
19
2.2.4. SQL
A SQL (Structured Query Language – Linguagem Estruturada de Consulta)
permitiu padronizar a construção e ace...
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...
21
departamentos e banco de dados – entre outros – de uma forma transparente e organizada,
permitindo ao desenvolvedor cri...
22
Figura 2.4 – Um elemento XML complexo chamado <projetos> – Fonte: [ AVATHE, 2005]
A abordagem sobre cluster e grid comp...
23
Capítulo 3
Trabalhos Relacionados
Neste capítulo é apresentada uma visão geral sobre as soluções adotadas pelos
SGBDs O...
24
3.1.1.1. Arquitetura do Real Application Cluster
A arquitetura física do RAC (figura 3.1) é dividida em camadas, onde n...
25
O Oracle Clusterware monitora e gerencia o RAC, dessa maneira se houver uma
falha o Oracle Clusterware irá reiniciar au...
26
• Servidor de Balanceamento (Load Balancer): Recebe consultas e as
encaminha para os nós de armazenamento. As consultas...
27
Figura 3.3 – Sistema de alta disponibilidade – Fonte: [GOVER OELETRO ICO, 2008]
3.2.2. PGPool
O PGPool é uma solução qu...
28
Figura 3.4 – Replicação em Cascata – Fonte: [SLO Y, Introducing, 2008]
Segundo [SLONY, 2008], Slony-I é um sistema repl...
29
3.2.4. ParGRES
O ParGRES é um middleware projetado com o objetivo de ser capaz de processar
consultas pesadas com grand...
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....
31
A figura 3.7 mostra a arquitetura do middleware proposto. Ele é formado por
artefatos denominados Agentes, que desempen...
32
• Agente Servidor – Base de Dados: Qualquer fonte de informação disponível
em ambiente computacional ou em interfaces. ...
33
3.3.3. Pontos Fracos do Middleware
A implementação do middleware proposto em [JUNIOR, 2005] se caracterizou por
Indepen...
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áqui...
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...
36
3.5. Conclusão
Embora o Oracle e o PostgreSQL apresentem soluções para resolver o problema de
escalabilidade, todas ela...
37
heterogêneas. O middleware apresentado nesta dissertação vai mais além da proposta de
[JUNIOR, 2005]. Além do compartil...
38
Capítulo 4
O Middleware LUCAS-GABRIEL
Este capítulo apresenta o middleware proposto nesta dissertação, o qual foi
denom...
39
Figura 4.1 – Middleware proposto
Esta arquitetura deixa o gerenciamento dos dados mais complexo, porém, em
contra-parti...
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 ...
41
Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware
O esquema do arquivo XML gerado está diretamente relacionado...
42
nomes destas tags são iguais aos nomes dos atributos da tupla retornada pela consulta, e no
seu conteúdo estão os valor...
43
Figura 4.5(b) – Diagrama de classe do LUCAS
Detalhamento da (i) classe ClientSocket, do (ii) tipo enumerado Tipo_Solici...
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 relaciona...
45
A classe ServerSocket é responsável por gerenciar as conexões e solicitações
enviadas pela classe ClientSocket, enquant...
46
LUCAS.Clear;
LUCAS.SetTabela(‘Cliente’);
LUCAS.SetDados(‘Nome’, ‘José da Silva’);
LUCAS.SetDados(‘Endereco’, ‘Rua Todos...
47
Figura 4.7(b) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes LUCAS e Clien...
48
Figura 4.7(d) – Diagrama de Seqüência – Incluir registro independente
Mensagens trocadas entre as classes ServerSocket ...
49
4.4.1.2. Incluir registro dependente
A inclusão de um registro que possua chave estrangeira, e onde esta chave
estrange...
50
Figura 4.8(b) – Diagrama de Seqüência – Incluir registro dependente
Mensagens trocadas entre as classes LUCAS e ClientS...
51
O desconhecimento da chave primária do pedido pode causar inconsistência nos
dados, uma vez que se forem incluídos dois...
52
LUCAS.SetIncluir(False);
LUCAS.SetTabela(‘Pedido_Item');
LUCAS.SetChaveEstrangeira(‘Pedido’, 'ID_Pedido');
LUCAS.SetDad...
53
values (Pedido.Gerador_ID, ‘1234567890’, ‘2’);
insert into Pedido_Item (ID_Pedido, ID_Produto, Quant)
values (Pedido.Ge...
54
Figura 4.10 – Diagrama de Seqüência – Alterar registro
Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
Tend...
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Dissertação (56)
Próximos SlideShares
Carregando em…5
×

Dissertação (56)

229 visualizações

Publicada em

System MiddleWare

Publicada em: Software
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
229
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Dissertação (56)

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. À minha esposa Ylane, e aos meus filhos Lucas Gabriel e Cibelle.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.9 – Exemplo de RAIDb-1 Figura 3.10 – Exemplo de RAIDb-2 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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.
  18. 18. 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.
  19. 19. 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
  20. 20. 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.
  21. 21. 5 Capítulo 2 Fundamentação Teórica Antes de apresentar o middleware proposto, se torna necessário esclarecer alguns conceitos básicos que levaram a concepção desta proposta. Como o middleware proposto tem a finalidade de gerenciar a distribuição do armazenamento de dados entre banco de dados homogêneos e/ou heterogêneos, duas áreas do conhecimento – Computação Distribuída e Banco de Dados – devem ser apresentadas para o melhor entendimento da solução proposta. 2.1. Computação Distribuída Nesta seção são discutidos alguns conceitos sobre sistemas distribuídos. Não é pretensão desta seção exaurir o tema, uma vez que alguns dos tópicos apresentados têm informações e contestações suficientes para justificar a quantidade de livros, artigos, entre outras publicações acadêmicas. 2.1.1. Comunicação entre Processos Processos que rodam em vários sistemas finais podem comunicar-se. Segundo [KUROSE, 2006] “Um processo pode ser imaginado como um programa que está rodando dentro de um sistema final.”. Quando os processos estão rodando no mesmo sistema final é usada a comunicação interprocessos que é resolvida pelo sistema operacional final que define suas regras com base na proposta do seu projeto de criação e desenvolvimento. “ o contexto de uma sessão de comunicação entre um par de processos, o processo que inicia a comunicação (isto é, o primeiro a contatar o outro no início da sessão) é rotulado como cliente. O processo que espera ser contatado para iniciar a sessão é o servidor.” [KUROSE, 2006].
  22. 22. 6 2.1.1.1. Comunicação Síncrona e Assíncrona Nas comunicações síncronas quando o processo a envia (send) a mensagem o mesmo fica bloqueado até receber (receive) a mensagem de resposta do processo b. Nesse caso o send e receive causam bloqueio no processo. Nesse tipo de comunicação (i) o processo remetente envia uma mensagem de requisição pedindo autorização para iniciar a transmissão; (ii) recebendo a autorização o processo remetente inicia o envio (send) da mensagem; (iii) o envio (send) só é concluído após a recepção (receive) confirmando o recebimento; (iv) após concluir o processo os buffers e estruturas de dados são liberados. Necessitando-se de um processo que após o envio da mensagem (send) não fique bloqueado pela recepção (receive), deve-se utilizar a comunicação assíncrona. Nesse caso a operação send é não bloqueante. Enquanto o receive pode tanto ser bloqueante quanto não bloqueante. No receive bloqueante o send é liberado após a mensagem ter sido copiada para um buffer local. Em seguida, o processo remetente pode reutilizar o seu buffer, mas não tendo como garantia o sucesso da transmissão anterior. O receive da comunicação assíncrona bloqueante assemelha-se com o receive da comunicação síncrona. “ a variante não bloqueante, o processo destino prossegue sua execução após ter realizado a operação receive, a qual fornece um buffer para ser preenchido em background. este caso, o processo deve receber separadamente uma notificação de que seu buffer possui dados a serem lidos, isso pode ser feito baseado em polling ou em interrupção.” [COULOURIS, 2007]. 2.1.1.2. Troca de Mensagens Quando se deseja criar uma comunicação entre um processo cliente e servidor pode-se usar a troca de mensagem. Essas mensagens trocadas devem ter um protocolo de comunicação, uma vez que, para obter o resultado esperado, esse processo requer uma compreensão e cooperação entre o processo cliente e servidor. Segundo [TANENBAUM, 2003] “Este método de comunicação interprocessos usa duas primitivas, send e receive.”. O processo remetente envia uma solicitação ao processo destino via mensagem. Ao receber a mensagem o processo servidor avalia para iniciar o
  23. 23. 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:
  24. 24. 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].
  25. 25. 9 A evolução das redes de computadores, capacitando ligar vários computadores em uma rede e permitindo-os que desempenhem uma mesma tarefa, impulsionou o uso e evolução do cluster ao estágio atual, onde o cluster se tornou uma opção interessante nos departamentos de tecnologia das corporações. 2.1.3. Grid Computing A idéia de um modelo capaz de lidar com uma taxa de processamento elevada e ao mesmo tempo dividir esse processamento entre máquinas formando uma única máquina virtual, podendo ser acessada por uma LAN (Local Area etwork – Rede de Área Local) ou WAN (Wide Area etwork – Rede de Longa Distância), foi introduzida nos anos 90 com o grid computing. A analogia com as redes elétricas (power grids) é citada sempre que se deseja falar sobre grid computing. No caso das redes elétricas, quando se tem um equipamento que necessita de energia elétrica, basicamente, basta conectar na rede elétrica e a mesma proverá a energia necessária para o funcionamento do equipamento. Não é preciso saber de onde vem, em que momento foi gerada ou como foi transportada. A única coisa que interessa é que tenha o que se deseja – energia elétrica – no momento que se precisa. Da mesma maneira deve ser o grid computing, quando se precisar armazenar ou recuperar informações, processar uma quantidade relativamente grande de dados entre outros tantos recursos computacionais, basta conectar a máquina no grid computing e o mesmo proverá o que se deseja no momento que se precisa. “O termo grade (grid) é usado para se referir ao middleware que é projeto para permitir o compartilhamento de recursos como arquivos, computadores, software, dados e sensores em uma escala muito grande. ormalmente, os recursos são compartilhados por grupos de usuários em diferentes organizações, os quais estão colaborando na solução de problemas que exigem grandes números de computadores para resolvê- los, ou pelo compartilhamento de dados ou pelo compartilhamento do poder de computação. Esses recursos são necessariamente suportados por hardware, sistemas operacionais, linguagens de programação e aplicações heterogêneas. É necessário gerenciamento para coordenar o uso de recursos para garantir que os clientes obtenham o que precisam e
  26. 26. 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.
  27. 27. 11 Embora alguns middleware só suportem uma linguagem de programação, comumente, o middleware é uma camada de software que oferece abstração de programação. “O middleware foi definido... como uma camada de software cujo o objetivo é mascarar a heterogeneidade e fornecer um modelo de programação conveniente para os programadores de aplicativos... Em particular, ele simplifica as atividades de comunicação de programas aplicativos por meio do suporte de abstração como a invocação a métodos remotos, a comunicação entre um grupo de processos, a notificação de eventos, o particionamento, posicionamento e recuperação de objetos de dados compartilhado entre computadores, a replicação de objetos de dados compartilhados e a transmissão de dados multimídia em tempo real.” [COULOURIS, 2007]. 2.2. Banco de Dados Esta seção apresenta alguns tópicos sobre banco de dados que devem ser conhecidos, uma vez que a arquitetura proposta foi criada para distribuir de maneira balanceada os dados armazenados. 2.2.1. Banco de Dados e Sistema Gerenciador de Banco de Dados A diferença entre banco de dados e Sistema Gerenciador de Banco de Dados (SGBD) deve ficar bem clara para entender os conceitos que se seguem. Um banco de dados deve ser projetado para o armazenamento de fatos que possuem um significado implícito, representando aspectos do mundo real. O conjunto de informações (dados) armazenado deve ter um significado efetivo que atende um propósito específico. “... um banco de dados possui algumas fontes das quais os dados são derivados, alguns níveis de interação com os eventos do mundo real e um publico efetivamente interessado em seus conteúdos.” [ AVATHE, 2005]. Um SGBD é um conjunto de programas que permite a criação e manipulação do banco de dados, facilitando os processos de definição, construção, manipulação e compartilhamento dos dados.
  28. 28. 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.
  29. 29. 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
  30. 30. 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
  31. 31. 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.
  32. 32. 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.
  33. 33. 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
  34. 34. 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
  35. 35. 19 2.2.4. SQL A SQL (Structured Query Language – Linguagem Estruturada de Consulta) permitiu padronizar a construção e acesso a SGBDR (Sistema de Gerenciamento de Bancos de Dados Relacional) de diferentes tipos e em diferentes plataformas de software e hardware. Essa padronização impulsionou não apenas a disseminação dos SGBDR, mas também a própria SQL. Para entender a importância da SQL são mostrados nesta subseção todos os pontos que levaram os DBAs (Database Administrator – Administrador de Banco de Dados) a ter na SQL um aliado importante. No final da década de 1960 o matemático Edgar Frank Codd apresentou as primeiras idéias sobre banco de dados relacional. Em junho de 1970 publicou o artigo “A relational model of data for large shared data banks – Um modelo relacional de dados para grandes bancos de dados compartilhados”, o que lhe rendeu em 1981 o prêmio ACM TURING AWARD2.1 . Em 1973 a IBM criou o seu primeiro gerenciador de dados relacional, o SYSTEM R que utilizava a linguagem de consulta SEQUEL (Structured English Query Language – Linguagem Inglesa Estruturada de Consulta). Por motivos legais, a sigla foi alterada para SQL, mas o primeiro SGBDR disponível comercialmente foi o ORACLE em 1979. A primeira versão padronizada da SQL ocorreu em 1986, ficando conhecida como SQL-86. Esse padrão foi inicialmente desenvolvido no âmbito da ANSI (American ational Standards Institute – Instituto Nacional Americano de Padrões) sendo aprovado pela ISO (International Organization for Standardization – Organização Internacional para Padronização) em 1987. Em 1989 foi publicada uma extensão do padrão SQL-86 chamada de SQL-89. A SQL-92, também chamada de SQL2, foi publicado em 1992 e aprovado pela ISO. Essa versão da SQL foi dividida tem três partes: 1. Entry Level (Nível de Entrada) – Nesse nível foi definido um conjunto mínimo de comando para ser considerado padrão SQL 2. Intermediate level (Nível Intermediário) 2.1 O prêmio ACM TURING AWARD é conferido a uma pessoa que tenha dado contribuições de natureza técnica a comunidade computacional
  36. 36. 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,
  37. 37. 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]
  38. 38. 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.
  39. 39. 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.
  40. 40. 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.
  41. 41. 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:
  42. 42. 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.
  43. 43. 27 Figura 3.3 – Sistema de alta disponibilidade – Fonte: [GOVER OELETRO ICO, 2008] 3.2.2. PGPool O PGPool é uma solução que fica numa camada entre o cliente e servidor de dados com a finalidade de prover alta disponibilidade, replicação e balanceamento de carga. “Como sistema de replicação de dados, PGPool permite backup em tempo real de bancos de dados, enviando as mesmas declarações SQL para ambos os servidores, podendo ser considerado um sistema de replicação síncrona... Se algum problema torna um dos servidores PostgreSQL indisponível, o PGPool tenta continuar o serviço com o servidor ainda ativo.” [GOVER OELETRO ICO, 2008]. As consultas são distribuídas de maneira aleatória entre os nós para obter um ganho de desempenho, balanceando a carga entre esses nós. Utilizando o PGPool como middleware os aplicativos que utilizam o PostgreSQL não precisam ser modificados. Já o número de conexões com o PostgreSQL pode ser configuráveis. O PGPool-II é uma evolução do PGPool, que suporta até 128 nós, com poder de processamento paralelo nos nós. 3.2.3. Slony-I O Slony-I é um sistema de replicação que segue o modelo Master to Multiple Slaves apoiado no cascateamento de slaves e failover. Com essa estrutura é possível garantir que um Slave assuma a posição de Master caso um Master venha a falhar. O Slony-I também se responsabiliza em usar rotas alternativas sempre que um Slave responsável pela transmissão dos dados falhe. O tipo de replicação de banco de dados adotado pelo Slony-I foi a replicação assíncrona em cascata (figura 3.4).
  44. 44. 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]
  45. 45. 29 3.2.4. ParGRES O ParGRES é um middleware projetado com o objetivo de ser capaz de processar consultas pesadas com grandes quantidades de dados. Porém para que ele possa ser utilizado o PostgreSQL deve estar sobre um cluster de PCs. O processamento da consulta usa o paralelismo intra-consultas3.1 e inter-consultas3.2 . O ParGRES consiste em uma camada intermediária de software que gerencia instâncias de SGBDs executados em diferentes nós de um cluster, implementando técnicas de processamento paralelo. Segundo [MATTOSO, 2009] “seus componentes se encontram distribuídos entre os nós do cluster”. Dessa maneira o ParGRES possui uma arquitetura descentralizada como mostrado na figura 3.6. Figura 3.6 – Arquitetura do ParGRES – Fonte: [MATTOSO, 2009] “ParGRES está sendo desenvolvido em Java, e os testes estão sendo executados em um cluster de PCs seguindo arquitetura de memória distribuída. Pela sua arquitetura, o ParGRES não necessita em absoluto de hardware específico de clusters... a implementação atual do ParGRES está sendo utilizado o SGBD PostgreSQL versão 8.0 em cada 3.1 “Significa decompor consultas complexas em sub-consultas que serão executadas em paralelo, cada sub- consulta em um fragmento de dados diferente. Dessa forma, cada sub-consulta poderá então ser enviada para o nó que possui o respectivo fragmento dos dados. Assim, cada sub-consulta é enviada para um nó diferente e executada em paralelo com as demais” [MATTOSO, 2009]. 3.2 “Consultas distintas são executadas de forma concorrente no cluster de banco de dados, uma em cada nó do cluster” [MATTOSO, 2009].
  46. 46. 30 nó do cluster. A comunicação entre o ParGRES e cada nó do cluster é realizada através de JDBC.” [MATTOSO, 2009]. 3.2.4.1. Arquitetura Na arquitetura do ParGRES existem componentes globais e locais. As tarefas que envolvem vários nós do cluster são executadas pelos componentes globais, enquanto as tarefas que são realizadas em apenas um nó são executadas pelos componentes locais. Os componentes locais são os NQP ( ode Query Processor – Processador de Consultas de Nó) e o PostgreSQL, enquanto os componentes globais são o Intermediador e o CQP (Cluster Query Processor – Processador de Consultas de Cluster). O Intermediador repassa as requisições das aplicações para o CQP, e do CQP para as aplicações. Dessa maneira o Intermediador provê maior flexibilidade na alocação física do CQP, aumentando o grau de tolerância a falhas do ParGRES. 3.2.4.2. Cluster Query Processor O CQP é o componente mais importante do ParGRES, ele age como gerenciador dos outros componentes, sendo responsável por controlar a execução de requisições do ParGRES. As informações presentes no Catálogo do ParGRES são utilizadas pelo CQP para analisar as consultas e definir que tipo de paralelismo deverá ser usado. O Catálogo armazena informações necessárias para a fragmentação virtual adaptativa, não precisando de informações específicas do SGBD. 3.2.5. Pontos Fracos nas Soluções do PostgreSQL As soluções do PostgreSQL têm como foco a replicação dos dados. Nenhuma das soluções trata a escalabilidade como foco primordial. Em alguns a escalabilidade é tratada como um problema secundário. Em outros nem isso é apresentado. Além disso, todas são soluções direcionadas ao PostgreSQL. 3.3. Modelo para o Compartilhamento de Bases de Dados Distribuídas e Heterogêneas No seu trabalho apresentado por [JUNIOR, 2005] é proposto um modelo para viabilizar o “Compartilhamento de Bases de Dados Distribuídas e Heterogêneas”
  47. 47. 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.
  48. 48. 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.
  49. 49. 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.
  50. 50. 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. Figura 3.9 – Exemplo de RAIDb-1 – Fonte: [GOVER OELETRO ICO, 2008]
  51. 51. 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. Figura 3.10 – Exemplo de RAIDb-2 – Fonte: [GOVER OELETRO ICO, 2008] 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.
  52. 52. 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
  53. 53. 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.
  54. 54. 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.
  55. 55. 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
  56. 56. 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.
  57. 57. 41 Figura 4.4 – Exemplo de arquivo XML gerado pelo middleware O esquema do arquivo XML gerado está diretamente relacionado com o metadado da origem dos dados, mas três tags são comuns a todos os arquivos XML gerados: • <?xml version="1.0" encoding="ISO-8859-1"?> Esta tag especial define a versão do documento XML através do atributo version, enquanto o atributo encoding define a tabela caracteres que será usada no arquivo. Esta tag deve aparecer apenas uma vez no arquivo XML • <dados> Local onde os registros ficam armazenados. Esta tag deve aparecer apenas uma vez no arquivo XML. • <registro> Define uma tupla e os valores armazenados em seus atributos. Esta tag pode aparecer uma vez, várias vezes ou nenhuma vez no arquivo XML, o que define a quantidade de vezes é o resultado gerado pela consulta. Ainda analisando o exemplo apresentado na figura 4.4 tem-se as tags < OME>, <E DER>, <BAIRRO>, <CEP>, <CIDADE> e <UF> dentro da tag <registro>. Os <?xml version="1.0" encoding="ISO-8859-1"?> <dados> <registro> <NOME>SAULA SAMPAIO BRINGEL IZIDORO</NOME> <ENDER>RUA PADRE CICERO</ENDER> <BAIRRO>MATRIZ</BAIRRO> <CEP>63.000.000</CEP> <CIDADE>JUAZEIRO DO NORTE</CIDADE> <UF>CE</UF> </registro> <registro> <NOME>TADEU PEREIRA LIMA FRANCA</NOME> <ENDER>RUA PADRE CICERO</ENDER> <BAIRRO>MATRIZ</BAIRRO> <CEP>63.000.000</CEP> <CIDADE>JUAZEIRO DO NORTE</CIDADE> <UF>CE</UF> </registro> </dados>
  58. 58. 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.
  59. 59. 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.
  60. 60. 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
  61. 61. 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:
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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 Mensagens trocadas entre o Sistema Cliente e a classe LUCAS
  66. 66. 50 Figura 4.8(b) – Diagrama de Seqüência – Incluir registro dependente Mensagens trocadas entre as classes LUCAS e ClientSocket Uma venda via pedido é um cenário onde se inclui registros dependentes. A chave primária do pedido é chave estrangeira para seus itens, mas a chave primária só será conhecida no momento da inclusão.
  67. 67. 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’);
  68. 68. 52 LUCAS.SetIncluir(False); LUCAS.SetTabela(‘Pedido_Item'); LUCAS.SetChaveEstrangeira(‘Pedido’, 'ID_Pedido'); LUCAS.SetDados(‘ID_Produto’, ‘1234567890’); LUCAS.SetDados(‘Quant’, ‘2’); LUCAS.SetIncluir(False); LUCAS.SetDados(‘ID_Produto’, ‘0987654321’); LUCAS.SetDados(‘Quant’, ‘5’); LUCAS.SetIncluir(False); 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)
  69. 69. 53 values (Pedido.Gerador_ID, ‘1234567890’, ‘2’); insert into Pedido_Item (ID_Pedido, ID_Produto, Quant) values (Pedido.Gerador_ID, ‘0987654321’, ‘5’); A figura 4.9 mostra o fluxograma para inclusão de dados. Figura 4.9 – Fluxograma para inclusão de dados 4.4.2. Alterar A alteração de dados se assemelha com a inclusão de dados. A diferença básica está no tocante ao método SetChaveEstrangeira, que neste caso é desprezado pelo método SetRequisitar, uma vez que, em uma alteração, a chave estrangeira já é conhecida. O algoritmo usado pelo GABRIEL replica a solicitação enviada pelo LUCAS em todos os servidores. A desvantagem dessa escolha é a perda de desempenho da rede, pois a mesma solicitação é enviada ao vários servidores. A vantagem é o ganho de desempenho dos servidores, devido cada servidor ter que processar uma quantidade menor de dados. O diagrama de seqüência da alteração de dados é mostrado na figura 4.10, a continuação desse diagrama é semelhante ao mostrado nas figuras 4.7(b) à 4.7(f). Não Sim Não Sim NãoSim Inicio SetTabela [SetChaveEstrangeira] SetDados Novos Dados SetIncluir Requisitar Fim SetRequisitar Nova Tabela Clear
  70. 70. 54 Figura 4.10 – Diagrama de Seqüência – Alterar registro Mensagens trocadas entre o Sistema Cliente e a classe LUCAS Tendo como base os dados da tabela 4.3, é mostrado a seguir como o Sistema Cliente deve efetuar a alteração neste registro. Tabela 4.3 – Alterar registro Tabela: Cliente Campo Valor Atual ovo Valor ID 150 Nome José da Silva Endereco Rua Todos os Santos Rua Padre Cícero Cidade Juazeiro do Norte UF CE O código que deverá ser executado: LUCAS.Clear; LUCAS.SetTabela(‘Cliente’); LUCAS.SetDados(‘Endereco’, ‘Rua Padre Cicero’); LUCAS.SetAlterar(‘ID = 150’, True); O comando SQL gerado (Leia Apêndice F): update Cliente

×