Ciência da Computação

Replicação em Banco de Dados Distribuídos Heterogêneos

Cleidenilson Santiago da Silva

Salvador-BA...
Cleidenilson Santiago da Silva

Replicação em Banco de Dados Distribuídos Heterogêneos

Monografia apresentada ao Curso de...
TERMO DE APROVAÇÃO

Cleidenilson Santiago da Silva

Replicação em Banco de Dados Distribuídos Heterogêneos

Monografia apr...
AGRADECIMENTOS

Agradeço primeiramente a Deus, por ter me ajudado e me conduzido para
que eu pudesse alcançar essa benção ...
RESUMO

Com a crescente demanda de armazenamento e acesso de dados, é necessário o
uso de mecanismos que possam garantir a...
ABSTRACT

With the increasing demand for storing and accessing data, using mechanisms to
ensure the availability, security...
LISTA DE FIGURAS

Figura 1 - Representação Simplificada de um sistema de banco de dados. ............ 11
Figura 2 - Repres...
SUMÁRIO

1 INTRODUÇÃO .......................................................................................................
3.7.3 Cópia Primária ........................................................................................... 28
3.7.4 ...
10

1 INTRODUÇÃO

1.1 Objetivo

Este trabalho tem como objetivo demostrar o funcionamento da replicação
entre banco de dad...
11

2 SISTEMA DE BANCO DE DADOS

Conforme Date (2003):

Um sistema de banco de dados é basicamente um sistema
computadoriz...
12

de dados também é armazenada pelo SGBD na forma de metadados que é também
conhecida como catálogo ou dicionário.

2.1 ...
13

•

Proteção - Os dados podem ser mais bem protegidos contra perda não
intencional e acesso ilegal.

2.3 Linguagem de B...
14

=122346

▪ Delete - É uma instrução que remove um ou mais registro de uma tabela, uma
condição deve ser definido a, pa...
15

é baseada nesse modelo.

2.4.2 Modelo Entidade / Relacionamento

Este modelo é baseado em uma percepção de um real que...
16

3 SISTEMA DE BANCO DE DADOS DISTRIBUÍDO

Segundo Date (2003), um sistema de banco de dados distribuído
basicamente con...
17

3.1 Tipos de Sistema de Banco de Dados Distribuídos

Segundo Casanova (1999) o sistema gerenciador de banco de dados
d...
18

uma arquitetura ou outra é influenciada pelo aproveitamento de "hardware" e
"software" já existentes e pelo próprio há...
19

que apresentou falha tiverem sido duplicados em outro site antes da falha,
então o usuário não será afetado de forma a...
20

Figura 3 - Variação de Arquitetura
Fonte: (ÖSZU; VALDIUREZ, 2011, p.25).

A autonomia, neste caso se se refere à distr...
21

compartilhados entre si.
•

Distribuição não hierárquica: Não existe distinção de máquinas clientes e
servidores, cada...
22

usando informações de distribuição e replicação de dados.
•

Otimização global de consulta : A otimização consiste em ...
23

Em um ambiente gerenciamento de banco de dados distribuídos o sistema
pode "esconder" os detalhes relativos à distribu...
24

Para se entender como o banco de dados distribuídos realiza o
armazenamento de dados é importante compreender alguns c...
25

●

Disponibilidade - Se um dos sites contendo os dados operacionais

falharem, então estes mesmos dados pode ser encon...
26

mais atributos da relação (ELMASRI; NAVATHE, 2011).

Os autores Korth, Silberschatz e Sudarshan (1999), definem a mesm...
27

Com o uso dessa técnica o sistema mantém apenas um gerenciador de
bloqueio que reside em um único site escolhido. Um s...
28

interrompido ou um esquema de recuperação precisa ser usado para que um site de
backup possa assumir o gerenciamento d...
29

item de dado Q, a solicitação aguarda até que possa ser conseguido, quando o
bloqueio é realizado , o administrador de...
30

3.7.6 Timestamp

A principal ideia do timestamp é que cada transação receba um "tempo"
exclusivo, que o sistema define...
31

4 REPLICAÇÃO

O processo de copiar e manter objetos de banco de dados em vários bancos
de dados que compõem um sistema...
32

Os sistemas mais adequados para essa estratégia de replicação são os que
possuem as seguintes características:
•

Nece...
33

● Baixo custo de comunicação - a internet ou intranet pode ser utilizada para
comunicação entre as réplicas.

● Aument...
34

de acesso ás informações do banco de dados, garantindo a disponibilização de
dados ou mais acesso localizado de dados ...
35

Na figura 5 temos uma representação do modelo mestre/escravo.

Figura 5 - Representação do modelo mestre/escravo.
Font...
36

negócio e que os dados sejam tratados corretamente em todos os sites. Além dos
conflitos que ocorrem em ambientes é im...
37

5 APLICAÇÃO

Para o ambiente de replicação será utilizada os seguintes componentes:

• VitualBox da Oracle para a cria...
38

Servidor Escravo

Figura 7 - Máquina virtual que funcionará como servidor escravo.
Fonte: Elaborado pelo autor.

O ban...
39

Figura 8 - Diagrama de Entidade de Relacionamento D.E.R
Fonte: Elaborado pelo autor.

Foi utilizado o seguinte código ...
40

CREATE TABLE Funcionario
(
idFunc NUMBER (7,1) NOT NULL ,
Nome VARCHAR2 (45) ,
Cpf

VARCHAR2 (11) ,

Rg

VARCHAR2 (10)...
41

escravo (MySQL) conforme a figura 9:

Figura 9 - Representação do Esquema de Replicação
Fonte: Elaborado pelo autor.

...
42

Figura 10 - Configurando ODBC MySQL
Fonte: Elaborado pelo autor.

No arquivo listener.ora que está localizado no diret...
43

(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = servidor-9dd59b)(PORT = 1521))
(CONNECT_DATA =
(SID=ORACLE_MYSQL)
)
...
44

# This is a sample agent init file that contains the HS parameters that are
# needed for an ODBC Agent.
#
# HS init pa...
45

Agora fazemos a conexão entre o banco de dados Oracle e MySQL, conforme o
código SQL a seguir:

CREATE DATABASE LINK "...
46

END;

Criamos a procedure para exclusão de dados na tabela funcionário, conforme o
código SQL a seguir:

create or rep...
47

BEGIN
procINSERT(:NEW.idFunc, :NEW.nome, :NEW.cpf, :NEW.rg, :NEW.cargo);
END;

Agora vamos criar a trigger que irá cha...
48

PROCEDURE procINSERTdepen(i NUMBER, ii NUMBER,n VARCHAR2, cp
VARCHAR2,rg VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
B...
49

conforme o código SQL a seguir.

create or replace
TRIGGER tgINSERTdepen
AFTER INSERT ON dependente
REFERENCING NEW AS...
50

:NEW.nome, :NEW.cpf, :NEW.rg);
END;

5.2 Testes

O teste de replicação será realizado na tabela de funcionário com as ...
51

Como podemos ver de os dados foram replicados para o MySQL, conforme a figura
14:

Figura 14 - Dados Replicados Para o...
52

Será realizada a atualização de um registro no banco de dados da Oracle conforme
a figura 15:

Figura 15 - Atualizando...
53

Podemos ver que a atualização também ocorreu no MySQL conforme a figura 16:

Figura 16 - Dados Atualizados no MySQL
Fo...
54

Agora será realizada a exclusão de um registro no banco de dados da Oracle
conforme a figura 17:

Figura 17 - Excluído...
55

Como pode ser visto o registro foi excluído no banco de dados MySQL conforme a
figura 18:

Figura 18 - Registro Excluí...
56

5.3 Considerações

Conforme os testes realizados, pode-se observar que todas as operações
realizadas no banco de dados...
57

6 CONSIDERAÇÕES FINAIS

Como foi visto a replicação de dados oferece muitas vantagens como
desempenho, disponibilidade...
58

REFERÊNCIAS

BOSS, Líbia. Replicação de Dados Disponível em: <http://prezi.com/axoc
18nzbmtm/ replicacao-de-dados/> Ac...
59

RAMALHO, J. A. ORACLE 10G. 1º. ed. São Paulo: Thomson Pionera , 2005. 377p.

RAMOS, Wagner.
Replicação de Dados Dispon...
Próximos SlideShares
Carregando em…5
×

Manografia Replicação em banco de dados distribuídos heterogêneos

4.583 visualizações

Publicada em

Manografia Replicação em banco de dados distribuídos heterogêneos

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

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

Nenhuma nota no slide

Manografia Replicação em banco de dados distribuídos heterogêneos

  1. 1. Ciência da Computação Replicação em Banco de Dados Distribuídos Heterogêneos Cleidenilson Santiago da Silva Salvador-BA 2013
  2. 2. Cleidenilson Santiago da Silva Replicação em Banco de Dados Distribuídos Heterogêneos Monografia apresentada ao Curso de Bacharelado em Ciências da Computação da Faculdade IBES, como requisito parcial para obtenção do grau de Bacharel. Orientador: Prof. Roberto Carlos Sarmento Barbosa Salvador-BA 2013
  3. 3. TERMO DE APROVAÇÃO Cleidenilson Santiago da Silva Replicação em Banco de Dados Distribuídos Heterogêneos Monografia aprovada como requisito parcial para obtenção do grau de Bacharel em Ciências da Computação, pela seguinte banca examinadora: _________________________________________ Prof. Carlos Roberto Sarmento Barbosa Orientador _________________________________________ Prof. Carlos Henrique Examinador _________________________________________ Prof. Vicente Cardoso Examinador Aprovado em ____/___/_____. Salvador-BA 2013
  4. 4. AGRADECIMENTOS Agradeço primeiramente a Deus, por ter me ajudado e me conduzido para que eu pudesse alcançar essa benção na minha vida. Ao meu pai Armando Ferreira da Silva que não mediu esforços para me proporcionar uma vida melhor e que foi um exemplo para mim, sempre batalhador, dedicado e esforçado. A minha mãe Cleidenice Santiago que sempre esteve ao meu lado durante o desenvolvimento desse trabalho nunca deixando eu me desviar dos meus objetivo essa ajuda muito importante para a conclusão desse trabalho. Ao meu primo Lídio que investiu e acreditou em mim, ao meu tio Durval por ter me ajudado e incentivado a minha qualificação, agradeço também ao Bispo Júlio e a Bispa Lindinalva pela dedicação e atenção. Ao professor Sarmento por ter me orientado, pela grande contribuição e por ter me incentivado, essa grande ajuda viabilizou o desenvolvimento desse trabalho. Aos meus companheiros de sala João Guedes, Thyago Souza, Jorge Luiz, Rodrigo Franco, Jorge Antônio, Robson Oliveira, Guilherme Matos, Luís Paulo, Cris e Fernando pelo companheirismo durante esses 4 anos. A todos os meus professores do curso de ciência da computação pela grande contribuição na minha vida, que possibilitou a concretização da minha graduação.
  5. 5. RESUMO Com a crescente demanda de armazenamento e acesso de dados, é necessário o uso de mecanismos que possam garantir a disponibilidade, segurança e acesso dessas informações independente da sua localização, a descentralização vem ganhando espaço a cada dia que passa fortalecendo assim o uso de banco de dados distribuídos. Em ambientes corporativos é natural as informações estarem espalhadas em diversas localidades sendo necessária a consolidação de tais dados. Quando as empresas são incorporadas na maioria das vezes se torna necessário a replicação das informações para banco de dados de fabricantes distintos, possibilitando a integração entre sistemas e o reaproveitamento de infra-estrutura existente, minimizando os custos com equipamentos e manutenções. Neste trabalho será abordado as questões inerente da replicação de dados, bem como o desenvolvimento de um ambiente de replicação entre base dados da Oracle e MySQL, utilizando máquinas virtuais. Palavras-chave: Disponibilidade; Banco de Dados Distribuídos; Replicação; Oracle; MySQL
  6. 6. ABSTRACT With the increasing demand for storing and accessing data, using mechanisms to ensure the availability, security and access these independently of the location information is required, decentralization is gaining momentum with each passing day thus strengthening the use of stock distributed data. In corporate environments is natural information are scattered in various locations consolidate such data is necessary. When companies are incorporated in most cases the replication of information to the database of different manufacturers becomes necessary, enabling the integration of systems and the reuse of existing infrastructure, minimizing equipment costs and maintenance. This work will address the inherent issues of data replication and the development of an environment database replication between Oracle and MySQL, using virtual machines. Keywords: Availability; Distributed Database; Replication; Oracle; MySQL
  7. 7. LISTA DE FIGURAS Figura 1 - Representação Simplificada de um sistema de banco de dados. ............ 11 Figura 2 - Representação do sistema de banco de dados distribuído (SGBDD)....... 16 Figura 3 - Variação de Arquitetura ............................................................................ 20 Figura 4 - Representação do modelo multimestre..................................................... 34 Figura 5 - Representação do modelo mestre/escravo. .............................................. 35 Figura 6 - Maquina virtual que funcionará como servidor mestre. ............................. 37 Figura 7 - Máquina virtual que funcionará como servidor escravo. ........................... 38 Figura 8 - Diagrama de Entidade de Relacionamento D.E.R .................................... 39 Figura 9 - Representação do Esquema de Replicação ............................................. 41 Figura 10 - Configurando ODBC MySQL .................................................................. 42 Figura 11 - Criando o Arquivo Init.............................................................................. 43 Figura 12 - Reiniciando o Banco de Dados Oracle ................................................... 44 Figura 13 - Inserindo Dados no Banco de Dados da Oracle .................................... 50 Figura 14 - Dados Replicados Para o MySQL........................................................... 51 Figura 15 - Atualizando Dados no Banco de Dados da Oracle ................................. 52 Figura 16 - Dados Atualizados no MySQL ................................................................ 53 Figura 17 - Excluído Um Registro no Banco de Dados da Oracle............................ 54 Figura 18 - Registro Excluído no MySQL .................................................................. 55
  8. 8. SUMÁRIO 1 INTRODUÇÃO ....................................................................................................... 10 1.1 Objetivo ............................................................................................................ 10 1.2 Organização do Trabalho ................................................................................. 10 2 SISTEMA DE BANCO DE DADOS ....................................................................... 11 2.1 Sistema Gerenciador de Banco de Dados ....................................................... 12 2.2 Vantagens do Banco de Dados ....................................................................... 12 2.3 Linguagem de Banco de Dados ....................................................................... 13 2.4 Modelo de Dados ............................................................................................. 14 2.4.1 Modelo Relacional ..................................................................................... 14 2.4.2 Modelo Entidade/Relacionalmento ............................................................ 15 2.4.3 Modelo Orientado a Objeto ........................................................................ 15 3 SISTEMA DE BANCO DE DADOS DISTRIBUÍDO ............................................... 16 3.1 Tipos de Sistema de Banco de Dados Distribuídos ........................................ 17 3.1.1 Bancos de Dados Homogêneo .................................................................. 17 3.1.2 Bancos de Dados Heterogêneos ............................................................... 17 3.2 Vantagens do Banco de Dados Distribuídos .................................................... 18 3.3 Arquitetura ....................................................................................................... 19 3.4 Processamento Distribuido de Consulta .......................................................... 21 3.5 Transparência de Dados .................................................................................. 22 3.5.1 Transparência de Rede ............................................................................. 22 3.5.2 Transparência de Replicação .................................................................... 23 3.5.3 Transparência de Fragmentação ............................................................... 23 3.6 Armazenamento Distribuído dos Dados........................................................... 23 3.6.1 Replicação de Dados ................................................................................. 24 3.6.2 Fragmentação de Dados ........................................................................... 25 3.6.2.1 Fragmentação Horizontal .................................................................... 25 3.6.2.2 Fragmentação Vertical......................................................................... 26 3.6.2.3 Fragmentação Mista ............................................................................ 26 3.7 Controle de Concorrência ................................................................................ 26 3.7.1 Gerenciamento de Bloqueio Único ............................................................ 26 3.7.2 Gerenciador de bloqueio distribuído .......................................................... 28
  9. 9. 3.7.3 Cópia Primária ........................................................................................... 28 3.7.4 Protocolo da Maioria .................................................................................. 28 3.7.5 Protocolo Parcial ........................................................................................ 29 3.7.6 Timestamp ................................................................................................. 30 4 REPLICAÇÃO ........................................................................................................ 31 4.1 Estratégias de Replicação ............................................................................... 31 4.1.1 Replicação Síncrona .................................................................................. 31 4.1.2 Replicação Assícrona ................................................................................ 32 4.2 Modelos de Replicação .................................................................................... 33 4.2.1 Modelo Mutimestre .................................................................................... 33 4.2.2 Modelo Mestre/Escravo ............................................................................. 34 4.3 Objetos de Replicação ..................................................................................... 35 4.4 Conflitos de Replicação ................................................................................... 35 5 APLICAÇÃO .......................................................................................................... 37 5.1 Criação do Processo de Replicação ................................................................ 40 5.2 Testes .............................................................................................................. 50 5.3 Considerações ................................................................................................. 56 6 CONSIDERAÇÕES FINAIS ................................................................................... 57 REFERÊNCIAS ......................................................................................................... 58
  10. 10. 10 1 INTRODUÇÃO 1.1 Objetivo Este trabalho tem como objetivo demostrar o funcionamento da replicação entre banco de dados distribuídos heterogêneos, levando em consideração as vantagens e desvantagem do mesmo, explorando os principais conceitos de banco de dados e replicação de dados, provando assim que esse recurso pode ser utilizado em empresas, hospitais, universidades, entre outros. 1.2 Organização do Trabalho Esse trabalho está organizado da seguinte forma: no capítulo 2 temos uma abordagem com alguns conceitos importantes de banco de dados, no capítulo 3 são apresentado os fundamentos de banco de dados distribuídos com uma abordagem mais detalhada, no capítulo 4 é explorado os tópicos referentes à replicação de dados assim como os seus modelos e tipos. No capítulo 5 é realizado na prática a replicação de dados bem como as devidas configurações utilizando os banco de dados Oracle 10g e o MySQL 5.0.
  11. 11. 11 2 SISTEMA DE BANCO DE DADOS Conforme Date (2003): Um sistema de banco de dados é basicamente um sistema computadorizado de armazenamento de registros; isto é, um sistema computadorizado cujo propósito geral é armazenar informações e permitir ao usuário buscar e atualizar essas informações quando solicitado (DATE 2003, p.6). Os sistemas de banco de dados são projetados para gerir grandes volumes de informações, definir um banco de dados envolve especificar os tipos, estruturas e restrições dos dados armazenados. A definição ou informação descritiva do banco de dados também é armazenada pelo SGBD (NAVATHE, 2005). Na Figura 1 temos uma representação de um sistema de gerenciador de banco de dados. Figura 1 - Representação Simplificada de um sistema de banco de dados. Fonte: (DATE 2003). Para se definir um banco de dados é necessário especificar os tipos, estruturas e restrições de dados a ser armazenada, a definição descritiva do banco
  12. 12. 12 de dados também é armazenada pelo SGBD na forma de metadados que é também conhecida como catálogo ou dicionário. 2.1 Sistema Gerenciador de Banco de Dados Segundo Korth, Silberschatz e Sudarshan (2006) um Sistema Gerenciador de Banco de Dados (SGBD) é uma coleção de dados inter-relacionados, representando informações sobre um domínio específico. O SGBD é um sistema de software de uso geral que facilita o processo de definição, construção, manipulação e compartilhamento de banco de dados entre diversos usuários e aplicações. 2.2 Vantagens do Banco de Dados O banco de dados apresenta uma séria de vantagens levando em consideração o sistema de arquivos. Conforme Date (2003) as vantagens de utilizar um sistema de banco de dados (SGBD) são: • Densidade - Não há necessidade de arquivos em papel, possivelmente volumosos e com a possibilidade de perder todas as informações. • Velocidade - A máquina pode obter e atualizar dados com mais consistência e rapidez muito maior que o ser humano. • Menos trabalho monótono - Grande parte do tédio de manter arquivos à mão é eliminada. As tarefas mecânicas são em geral feitas com melhor qualidade por máquinas. • Atualidade - Informações precisas e atualizadas estão disponíveis a qualquer momento sob consulta.
  13. 13. 13 • Proteção - Os dados podem ser mais bem protegidos contra perda não intencional e acesso ilegal. 2.3 Linguagem de Banco de Dados Durante o desenvolvimento dos bancos de dados relacionais, foram criadas linguagens responsáveis pela sua manipulação, conforme Date (2003), SQL é a linguagem padrão utilizada para interagir com banco de dados relacionais, e atualmente é aceita pela maioria dos SGBDs disponíveis no mercado. A SQL inclui operações de definição de dados e operação de manipulação de dados, sendo composta por vários comandos tais como: ● Linguagem de definição de dados ou DDL (Data Definition Language) é responsável por permitir aos usuários acessar e manipular a dados, ela pode operar tanto no nível externo (sobre visões) quanto no nível conceitual (tabelas), e também oferece alguns recursos para controlar dados. O resultado da compilação dos parâmetros DDLs são armazenados em um conjunto de tabelas que compõe um arquivo especial chamado de dicionário de dados ou diretório de dados. ● Linguagem de manipulação de dados ou DML (Data Manipulation Language) é utilizada para recuperação, inclusão, remoção e modificação de informações de um banco de dados. As DDLs têm a sua capacidade funcional organizada pela palavra inicial em uma declaração, que na maioria das vezes é um verbo, temos os seguintes comandos SQL: ▪ Select - É uma declaração SQL que retorna um conjunto registros de uma ou mais tabelas. Exemplo: SELECT * FROM alunos ▪ Insert - É uma declaração SQL que inclui um ou mais registros em qualquer tabela de um banco de dados relacional. Exemplo: INSERT INTO alunos (matricula, nome) VALUES (José Ferreira, 122346) ▪ Update - É uma instrução que altera os dados de um ou mais registros em uma tabela. Exemplo: UPDATE alunos Set nome = José Ferreira Silva WHERE matricula
  14. 14. 14 =122346 ▪ Delete - É uma instrução que remove um ou mais registro de uma tabela, uma condição deve ser definido a, para evitar que todos os registro sejam removidos. Exemplo: DELETE FROM alunos WHERE matricula =122346 Segundo Korth, Silberschatz e Sudarshan (2006) a linguagem de manipulação de dados é responsável por viabilizar o acesso a manipulação de dados de uma forma apropriada e compatível com o modelo de dados, basicamente existe dois tipos: ▪ DMLs procedurais o usuário fica obrigado a especificar quais dados são necessário e como obtê-los. ▪ DMLs não procedurais o usuário fica obrigado a especificar quais dados são necessário sem especificar como obtê-los. 2.4 Modelo de Dados Segundo Korth, Silberschatz e Sudarshan (2006) o modelo de dados é uma coleção de ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições de consistência que visa apoiar a estrutura de um banco de dados. Ou seja, o modelo de dados representa todas as propriedades lógicas de armazenamento de dados. 2.4.1 Modelo Relacional Este modelo usa uma coleção de tabelas para representar os dados e relacionamentos entre elas, podemos dizer que o modelo relacional é um exemplo de um modelo baseado em registros. Conforme Korth, Silberschatz e Sudarshan (2006) o modelo de dados relacional é o modelo de dados mais utilizado, e a grande maioria dos SGDBs atuais
  15. 15. 15 é baseada nesse modelo. 2.4.2 Modelo Entidade / Relacionamento Este modelo é baseado em uma percepção de um real que consiste em uma coleção de objetos básicos, chamados de entidades, e as relações entre objetos (KORTH; SILBERSCHATZ; SUDARSHAN, 1999, p.7). 2.4.3 Modelo Orientado a Objeto Este modelo tem por base um conjunto de objetos, e esses objetos contém valores armazenados em variáveis instâncias dentro do objeto. Existe um conjunto de códigos que são utilizados para operar os objetos, chamamos esses conjuntos de código de métodos (KORTH; SILBERSCHATZ; SUDARSHAN, 1999, p.8).
  16. 16. 16 3 SISTEMA DE BANCO DE DADOS DISTRIBUÍDO Segundo Date (2003), um sistema de banco de dados distribuído basicamente consiste em uma coleção de sites, interligados através de algum tipo de rede de comunicações, onde: a. Cada site é ele próprio um site completo do sistema de banco de dados. b. Porém, os sites concordaram em atuar juntos, de modo que um usuário em qualquer site pode ter acesso aos dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site do próprio usuário. Decorre que o assim chamado “banco de dados distribuído” é na verdade uma espécie de banco de dados virtual, cujas partes componentes estão fisicamente armazenadas em vários bancos de dados “reais” distintos em vários sites distintos (na verdade, é a união lógica desses bancos de dados reais). Na figura 2 temos a representação de um Sistema de Banco de Dados Distribuído (SGBDD). Figura 2 - Representação do sistema de banco de dados distribuído (SGBDD). Fonte: (http://www.cos.ufrj.br/~marta/IntroductionP3.pdf).
  17. 17. 17 3.1 Tipos de Sistema de Banco de Dados Distribuídos Segundo Casanova (1999) o sistema gerenciador de banco de dados distribuídos (SGBDD) pode ser classificado em dois grandes grupos homogêneo e heterogêneo. 3.1.1 Bancos de Dados Homogêneos Chamamos de Banco de dados Homogêneo quando todos os sites possuem software de gerenciamento de banco de dados idênticos, ou seja, de um mesmo fabricante, ambos se conhecem e concordam em cooperar nas solicitações dos usuários do processamento. Conforme Elmasri e Navathe (2011) uma das características desse sistema é que os sites locais concordam em entregar parte da sua autonomia para ter direito de mudar esquemas ou software de sistema de gerenciamento de banco de dados. Segundo Casanova (1999), um SGBD distribuído será chamado de homogêneo (em "software") se os SGBDs locais forem semelhantes, mais precisamente, um SGBD distribuído é homogêneo se todos os seus SGBDs locais: ● Oferecer interfaces idênticas ou, pelo menos, da mesma família; ● Fornecerem os mesmo serviços aos usuários em diferentes nós. 3.1.2 Bancos de Dados Heterogêneos Um banco de dados é heterogêneo, quando os sites são distintos e podem usar diferentes esquemas e softwares de gerenciamento de banco de dados, pode ocorrer dos sites não ter ciência um do outro e oferecerem apenas facilidades limitadas para cooperação de processamento. Segundo Elmasri e Navathe (2011) a diversidade nos esquemas é um problema importante para o processamento da consulta, porém, a divergência de software se torna um obstáculo para o processamento de transações que acessam múltiplos sites. Conforme Casanova (1999), SGBDs distribuídos heterogêneos são quando os SGDBs locais forem distintos e geralmente é utilizada para integrar sistemas já existentes, a escolha por
  18. 18. 18 uma arquitetura ou outra é influenciada pelo aproveitamento de "hardware" e "software" já existentes e pelo próprio hábito e grau de cooperação esperado dos usuários em caso de uma mudança para um sistema diferente. 3.2 Vantagens do Banco de Dados Distribuídos Segundo Elmasri e Navathe (2011), as vantagens mais importantes dos bancos de dados distribuídos são: • Maior facilidade e Flexibilidade de desenvolvimento da Aplicação - O desenvolvimento e a manutenção de aplicações em sites geograficamente distribuídos de uma organização são facilitados devido à transparência da distribuição e controle de dados. • Maior confiabilidade e disponibilidade - Confiabilidade e disponibilidade são duas das vantagens em potencial mais comum citadas para bancos de dados distribuídos, onde: • Confiabilidade - É a probabilidade de um sistema estar funcionando (não parado) em certo ponto no tempo. • Disponibilidade - É a probabilidade de que o sistema esteja continuamente disponível durante um intervalo de tempo. Isso é obtido pelo isolamento de falhas ao seu site de origem, sem afetar os outros bancos de dados conectados à rede. Quando os dados e o software de SGBDD são distribuídos por vários sites, um destes pode apresentar falhas em enquanto os outros continuam a operar. Apenas os dados e software que existem no site defeituoso não poderão ser acessados. Isso melhora tanto a confiabilidade quanto a disponibilidade. Uma melhoria ainda maior é obtida pela devida replicação dos dados e software em mais de um site. Em um sistema centralizado, uma falha e um único site tornam o sistema inteiro indisponível a todos os usuários. Em um banco de dados distribuídos, alguns dos dados no site podem ficar inalcançáveis, mas os usuários ainda podem ser capazes de acessar outras partes do banco de dados. Se os dados no site
  19. 19. 19 que apresentou falha tiverem sido duplicados em outro site antes da falha, então o usuário não será afetado de forma alguma. • Maior desempenho - Um SGBD distribuído fragmenta o banco de dados ao manter os dados mais próximos de onde eles são mais necessários. A localização de dados reduz a disputa pela CPU e serviços de E/S e, ao mesmo tempo, reduz os atrasos nos acessos envolvidos nas redes remotas. Quando um banco de dados grande é distribuído por vários sites, existem bancos de dados menores em cada site. Como resultado, consultas e transações locais que acessam dados em um único site possuem melhor desempenho por causa dos bancos de dados locais menores. Além disso. Cada site tem um número menor de transações executando do que se todas as transações fossem submetidas a um único banco de dados centralizados. Ainda o paralelismo entre consultas e dentro da consulta pode ser alcançado ao executar várias consultas em diferentes sites, ou ao desmembrar uma consulta em uma série de sub-consultas executadas em paralelo. Isso contribui para melhorar o desempenho. • Expansão mais fácil - Em um ambiente distribuído, a expansão do sistema em matéria de inclusão de mais dados, aumento dos tamanhos do banco de dados ou inclusão de mais processadores é muito mais fácil. 3.3 Arquitetura A arquitetura de um sistema define a sua estrutura, ou seja, os componentes do sistema são identificados, é especificada a função de cada componente e as suas relações e interações. Segundo Özsu e Valdiurez (2011) no que diz respeito à arquitetura as possibilidades de projetar um SGBDD podem variar em de três dimensões: autonomia, distribuição e heterogeneidade, conforme é exemplificado na figura 3.
  20. 20. 20 Figura 3 - Variação de Arquitetura Fonte: (ÖSZU; VALDIUREZ, 2011, p.25). A autonomia, neste caso se se refere à distribuição de controle, e não dos dados necessariamente. Indicando o grau em que SGBD individuais podem operar independentemente. Autonomia é uma função de certo número de fatores, tais como se os sistemas de componente (isto é, SGBDs individuais) trocarem de informação, se eles podem, independentemente executar transações, e se é permitido modificá-los (ÖZSU; VALDIUREZ, 2011, p.25). A distribuição está relacionada à distribuição física de dados em múltiplos nós, sendo que os o usuários não sabem de qual maneira os dados estão distribuídos, ou seja, a distribuição é transparente ao usuário. De acordo com Özsu e Valdiurez (2011) um SGBD pode ser distribuído da seguinte maneira: • Cliente / Servidor: Os servidores concentram-se nas funções de gestão de dados, enquanto os clientes se concentram em o ambiente do aplicativo, incluindo a interface do usuário. Os deveres de comunicação são
  21. 21. 21 compartilhados entre si. • Distribuição não hierárquica: Não existe distinção de máquinas clientes e servidores, cada máquina possui toda a funcionalidade de um SGBD podendo se comunicar com as demais máquinas, executar consultas e transações. A Heterogeneidade pode ocorrer em várias formas, que vão de diferentes hardware e protocolos de redes de comunicação até variação nos modelos de dados, linguagens de consultas e protocolos de gerenciamento de transações (ÖZSU; VALDIUREZ, 2011). 3.4 Processamento Distribuído de Consulta Em sistemas distribuídos, é necessário levar em conta inúmeros fatores para aferir a resposta a uma consulta. O custo de transmissão de dados na rede e o ganho em se ter diverso localidades processando partes da consulta em paralelo são fatores importantes. Um ponto de equilíbrio deve ser encontrado entre transferência de dados na rede e transferência entre discos para garantir um baixo custo de transferência. De acordo com Elmasri e Navathe (2011) uma consulta em banco de dados distribuídos é processada em estágios da seguinte forma: • Mapeamento de consulta: A consulta de entrada em dados distribuídos é especificada formalmente usando uma linguagem de consulta, depois ela é traduzida para uma consulta algébrica em relações globais. Essa tradução é feita ao referir-se ao esquema conceitual global e não leva em conta a distribuição e replicação real dos dados. Portanto, essa tradução é em grande parte idêntica àquela realizada em um SGBD centralizado. Ou seja, ele é primeiro normalizado, analisado quanto a erros semânticos, simplificado e finalmente reestruturado em uma consulta algébrica. • Localização: Em um banco de dados distribuído, a fragmentação resulta em relações armazenadas em sites separados, com alguns fragmentos possivelmente sendo replicados. Esse estágio mapeia a consulta distribuída no esquema global para consultas separadas em fragmentos individuais
  22. 22. 22 usando informações de distribuição e replicação de dados. • Otimização global de consulta : A otimização consiste em selecionar uma estratégia com base em uma lista de candidatas que está mais próximo do ideal. Uma lista de consulta candidatas pode ser obtida ao permutar a ordenação das operações em uma consulta de fragmento gerada pelo estágio anterior. O tempo é a unidade utilizada para medir o custo. O Custo total é uma combinação ponderada de custos como o de CPU, os de E/S e aqueles de comunicação pela rede são os mais significativos. Isso é especialmente verdadeiro quando os sites são conectados por uma rede remota (WAN Wide Area Network). • Otimização de consulta local: É o estágio comum a todos os sites do BDD, as técnicas são semelhantes àquelas usadas nos sistemas centralizados. 3.5 Transparência de Dados A transparência “esconde” dos usuários finais os detalhes de implementação. Verifica-se também que segundo Elmasri e Navathe (2011) um sistema altamente transparente oferece mais flexibilidade ao usuário final/desenvolvedor de aplicação, pois não exige nenhum conhecimento ou conhecimentos básicos de sua parte. No banco de dados centralizados, a transparência pertence à independência lógica e física de dados para desenvolvedores de aplicação. Em um cenário de BDD, os dados e software são divididos por vários sites conectados por uma rede de computadores, de modo que tipos adicionais de transparência são introduzidos. Além disso, talvez seja preferível duplicar alguns desses dados em outros lugares por razões de confiabilidade e desempenho, que é conhecido como replicação de dados, o resultado é um banco de dados distribuído que é fragmentado e replicado. Para tratar de maneira adequada com este banco de dados distribuído, fragmentado e replicado, o sistema deve ser capaz de trabalhar com diversos tipos de transparências. 3.5.1 Transparência de Rede
  23. 23. 23 Em um ambiente gerenciamento de banco de dados distribuídos o sistema pode "esconder" os detalhes relativos à distribuição de dados na rede, minimizando a necessidade do usuário saber onde está a relação. A Transparência de rede pode ser dividida em transparência local e transparência de nomes, onde a transparência local refere-se ao fato que independente da localização dos dados e do nó onde o mesmo foi emitido, o comando será executado. A transparência de nomes significa que quando um nome é associado a um objeto, os mesmos podem ser encontrados sem ambigüidade (ELMASRI; NAVATHE, 2011). 3.5.2 Transparência de Replicação A transparência de replicação visa realizar várias cópias dos mesmos objetos de dados quem podem ser armazenados em vários sites para melhor disponibilidade, desempenho e confiabilidade, contudo os usuários não têm conhecimento da existência dessas cópias. 3.5.3 Transparência de Fragmentação A transparência de fragmentação oculta do usuário a existência de fragmentos, uma consulta global é transformada em várias consultas. Segundo Elmasri e Navathe (2011): Dois tipos de fragmentação são possíveis, horizontal e vertical. Na fragmentação horizontal as relações são distribuídas em sub relações (tabela) que são sub-relações de tuplas (linhas) na relação original. A fragmentação vertical distribui uma relação em subrelações em que cada uma é definida por um subconjunto das colunas da relação original (ELMASRI; NAVATHE, 2011, p.591). Ainda, segundo o autor existem outras transparências como: transparência de projeto e transparência de execução referindo-se à liberdade de saber como o banco de dados distribuído é projetado e onde uma transação é executada. 3.6 Armazenamento Distribuído dos Dados
  24. 24. 24 Para se entender como o banco de dados distribuídos realiza o armazenamento de dados é importante compreender alguns conceitos. Conforme Korth, Silberschatz e Sudarshan (1999), quando uma relação r é armazenada em um banco de dados, faz-se necessário abordar algumas questões quanto ao armazenamento dessas relações em um banco de dados distribuído, tais como: ● Replicação - O sistema mantem diversas réplicas idênticas de uma relação r. ● Fragmentação - A relação é dividida em vários fragmentos e esses fragmentos são armazenados em outro site. ● Replicação e fragmentação - É a junção dos itens apresentados anteriormente, a relação é dividida em vários pedaços e o sistema mantém diversas cópias de cada fragmento. 3.6.1 Replicação de Dados Replicação é o nome dado ao processo sincronização de entre dois ou mais servidores de banco de dados com o objetivo de garantir que os dados estejam disponíveis em dois ou mais servidores (KORTH; SILBERSCHATZ; SUDARSHAN, 1999, p.522). Para Elmasri e Navathe (2006) “A replicação é útil na melhoria da disponibilidade dos dados. O caso mais extremo é a replicação do banco de dados inteiro em todos os sites do sistema distribuído, criando assim, um banco de dados distribuído completamente replicado. Isso pode melhorar notavelmente a disponibilidade porque o sistema pode continuar operando desde que pelo menos um site esteja em operação” (ELMASRI; NAVATHE, 2011). Segundo Korth, Silberschatz e Sudarshan (1999) existem diversas vantagens e desvantagens na replicação de dados.
  25. 25. 25 ● Disponibilidade - Se um dos sites contendo os dados operacionais falharem, então estes mesmos dados pode ser encontrado em outro site. Desta forma o sistema pode continuar o processamento da consulta, mesmo com um site inoperante. ● Paralelismo aumentado - Como todos os sites terão os mesmos dados, as consultas realizadas geralmente ocorrerão nos servidores da rede local de cada cliente, com isso será minimizada a movimentação de dados entre os sites, melhorando a desempenho da rede que deixará de ficar sobrecarregada. ● Maior sobrecarga da atualização - Para garantir que todas as réplicas sejam consistentes é exigido mais controle do SGBD. Assim sempre que há uma atualização é necessária a atualização do todos os demais sites, com isso há uma maior sobrecarga para o sistema. 3.6.2 Fragmentação de Dados Quando uma relação é dividida em vários pedaços pode-se dizer que a mesma está fragmentada. Um sistema pode ser fragmentado e replicado, ou seja, uma relação pode ser particionada e cada uma dessas partições serem armazenada em locais distintos, isso é chamada de fragmentação Uma vez fragmentada é indispensável que cada fragmento possua as informações suficientes para recompor a relação no formato original. Essa reconstrução pode ser realizada por meio da aplicação de uma operação de união ou de um tipo especial de junção aos vários fragmentos. "Há dois esquemas diferentes para a fragmentação de uma relação: horizontal e vertical” (KORTH; SILBERSCHATZ; SUDARSHAN, 1999), existe também a fragmentação mista, porém alguns autores não classificam a mesma como um terceiro esquema de fragmentação. 3.6.2.1 Fragmentação Horizontal Uma fragmentação horizontal é um subconjunto das tuplas nessa relação. As tuplas que pertence ao fragmento são especificadas por uma condição de um ou
  26. 26. 26 mais atributos da relação (ELMASRI; NAVATHE, 2011). Os autores Korth, Silberschatz e Sudarshan (1999), definem a mesma como: “Quando uma relação é particionada em um número de subconjuntos cada tupla da relação pertence à pelo menos um fragmento, de modo que a relação original possa ser reconstruída se necessário” (KORTH; SILBERSCHATZ; SUDARSHAN, 1999). 3.6.2.2 Fragmentação Vertical O nó não precisa de todos os atributos de uma relação, essa técnica divide uma relação “verticalmente” através das colunas, um fragmento vertical de uma relação mantém apenas alguns atributos da relação. 3.6.2.3 Fragmentação Mista A fragmentação mista é a junção da fragmentação horizontal e vertical. 3.7 Controle de Concorrência O controle de concorrência é importante, pois garante que todas as transações simultâneas sejam executadas como se fosse a única, ou seja, em uma execução concorrente, as transações não devem gerar interferências que possam afetar a sincronização. Segundo Casanova (1999) as anomalias que ocorre com mais facilidades são perdas de atualizações, inconsistência no banco de dados e acesso a dados inconsistentes, as técnicas de controle de concorrência deve garantir que toda execução concorrente de um conjunto de transações seja serializável, equivalente a alguma execução das transações em que cada transação é completamente processada antes da seguinte começar. 3.7.1 Gerenciamento de Bloqueio Único
  27. 27. 27 Com o uso dessa técnica o sistema mantém apenas um gerenciador de bloqueio que reside em um único site escolhido. Um site é escolhido para tratar todas as solicitações de bloqueio e desbloqueio, se alguma transação necessitar bloquear um item de dados, ele enviar a solicitação para o site que foi escolhido para atender a todas solicitações. O gerenciador de bloqueio determina se o bloqueio pode ser concedido, se for possível atender a solicitação de bloqueio é enviada uma mensagem para o site que realizou a solicitação de desbloqueio, caso contrário a solicitação do site é postergada até que a mesma possa ser atendida. Quando uma mensagem é enviada ao site em que a solicitação de bloqueio foi iniciada, a transação pode ler o item de dados de qualquer um dos sites onde reside uma réplica (cópia) do item de dados. Já no caso da escrita, todos os sites em que reside uma réplica (cópia) do item de dados são obrigados a está envolvido na escrita. Segundo Korth, Silberschatz e Sudarshan (2006) esse esquema possui as seguintes vantagens: ● Implementação simples: Esse esquema requer duas mensagens para tratar de solicitações de bloqueio e uma mensagem para tratar de solicitação de desbloqueio. ● Tratamento de impasse simples: As solicitações de bloqueio e desbloqueios são feitas em apenas um site, os algoritmos de tratamento de impasse podem ser aplicados a esse ambiente. As desvantagens conforme Korth, Silberschatz e Sudarshan (2006) são as seguintes: ● Gargalo: O site se torna um gargalo, apresentando lentidão e acompanhado com altíssimas taxas de latência, pois todas as solicitações precisam ser processadas lá. ● Vulnerabilidade: Se o site responsável pelo controle de concorrência falhar o controlador de concorrência estará perdido, o processamento precisa ser
  28. 28. 28 interrompido ou um esquema de recuperação precisa ser usado para que um site de backup possa assumir o gerenciamento de bloqueio a partir do site defeituoso. 3.7.2 Gerenciador de bloqueio distribuído Na implementação da técnica do gerenciamento de bloqueio distribuído a função do gerenciamento de bloqueio é distribuída por diversos sites. Conforme Korth, Silberschatz e Sudarshan (2006) cada site possui um gerenciador de bloqueio local onde são administradas as solicitações de bloqueio e desbloqueio para os itens de dados que estão armazenados no site. Esse esquema tem a vantagem de implementação simples e reduz o gargalo do coordenador consequentemente. A sobrecarga é razoavelmente baixa, exigindo duas transferências de mensagens para lidar com solicitações de bloqueio e para tratar as solicitações de desbloqueio é apenas uma transferência de mensagem. 3.7.3 Cópia Primária A cópia primária é implementada quando um sistema utiliza a replicação de dados. “Assim, a cópia primária permite que o controle de concorrência para todos os dados replicados seja tratado como o controle de concorrência para dados não replicados” (KORTH; SILBERSCHATZ; SUDARSHAN, 2006, p.570). 3.7.4 Protocolo da Maioria É mantido um administrador de bloqueio local em cada site, cuja função é gerenciar as solicitações de bloqueio e desbloqueio para os itens de dados que estão armazenados naquele site. Segundo Korth, Silberschatz e Sudarshan (2006) quando uma transação solicita o bloqueio de um determinado item de dados Q, que não é replicado e reside em um site S, uma mensagem é enviada para o administrador de desbloqueio do site S solicitando o desbloqueio (em um modo de bloqueio em particular). Se o modo de bloqueio solicitado for incompatível com o
  29. 29. 29 item de dado Q, a solicitação aguarda até que possa ser conseguido, quando o bloqueio é realizado , o administrador de bloqueio envia uma mensagem de resposta informando que houve o bloqueio solicitado. Esse esquema possui a vantagem de ser implementado facilmente e exige a troca de duas mensagens para o tratamento de bloqueio e uma mensagem para o tratamento de desbloqueio. Uma as características desse esquema é que ele trabalha de maneira descentralizada dessa forma reduzindo os custos e o tráfego de dados. Contudo quando replicação de dados ele apresenta as seguintes desvantagens: ▪ Implementação - Esse protocolo tem implementação mais complicada que em relação a outros projetos. ▪Tratamento de Impasse - Já que as solicitações de bloqueio e desbloqueio é descentralizada, o algoritmos para tratamento de impasse não necessita de alteração, porém é possível que um impasse aconteça, até mesmo se apenas um item de dados estiver bloqueado. Entretanto é possível evitar esses impasses de modo fácil, solicitando que todos os sites realizem o bloqueio nas réplicas de um item de dados em uma ordem predeterminada. 3.7.5 Protocolo Parcial O Protocolo parcial basicamente é semelhante ao modelo do protocolo da maioria. Conforme Korth, Silberschatz e Sudarshan (2006) a principal diferença do protocolo da maioria é que as solicitações para bloqueios compartilhado são processadas mais favoravelmente do que as solicitações para bloqueio exclusivo, a seguir os detalhamentos dos bloqueios: ● Bloqueio compartilhamento - Se uma transação necessita do bloqueio de um item de dados Q, ela solicita o bloqueio de Q, através do gerenciador de bloqueio em todos os sites que possui uma replicação de Q. ● Bloqueios exclusivos - Se uma transação necessita bloquear um determinado item de dados Q, ela solicita um bloqueio sobre Q, a partir do gerenciador de bloqueio todos os sites que armazena uma réplica de Q.
  30. 30. 30 3.7.6 Timestamp A principal ideia do timestamp é que cada transação receba um "tempo" exclusivo, que o sistema define para decidir a ordem de serialização. Conforme Korth, Silberschatz e Sudarshan (2006) existem basicamente dois métodos para geração de um único registro de tempo, um centralizado e outro distribuído. No esquema centralizado, é escolhido um único site para a distribuição dos registros de horário. Contudo no esquema distribuído todos os sites geram um único registro de tempo global usando um contador lógico ou o relógio local. Para se obter um único registro de tempo global é necessário concatenar o registro de tempo único local com o identificador do site, que obrigatoriamente deve ser único.
  31. 31. 31 4 REPLICAÇÃO O processo de copiar e manter objetos de banco de dados em vários bancos de dados que compõem um sistema de banco de dados distribuídos é denominado de replicação. De acordo com a Ramalho (2005), as alterações aplicadas em um determinado local são captadas e armazenadas localmente, antes de serem enviados e aplicados a cada um dos locais remotos. A replicação utiliza a mesma tecnologia de banco de dados distribuído para compartilhar informações entre vários sites, contudo, um banco de dados replicado e um banco de dados distribuídos são distintos, pois em um banco de dados distribuídos as informações estão disponíveis em vários locais, porém, uma tabela específica reside apenas em um local. Enquanto na replicação os mesmos dados estão disponíveis em vários locais. A replicação é um ótimo recurso quando o objetivo é a distribuição de dados. 4.1 Estratégias de Replicação Em relação à replicação de dados existem basicamente duas estratégias de replicação, conhecidas como replicação síncrona e replicação assíncrona, onde cada uma pode ser utilizada de acordo com o tipo de sistema a ser implementado, necessidade de atualização de dados, desempenho e disponibilidade. 4.1.1 Replicação Síncrona Na replicação síncrona as alterações em um objeto são propagadas imediatamente para os demais objetos, as principais vantagens desta estratégia são a garantia da consistência de dados entre os objetos replicados, pois para a transação ser concretizada a mesma precisa ser confirmada em todos os objetos envolvidos e a baixa latência na atualização dos objetos replicados. Contudo as desvantagens se dão pelo excesso de operações que necessitam ser realizados para que uma atualização seja concluída, baixa escalabilidade e pela baixa autonomia que um objeto tem em relação aos demais (MELO, 2010).
  32. 32. 32 Os sistemas mais adequados para essa estratégia de replicação são os que possuem as seguintes características: • Necessidade de altas consistências das réplicas; • Possui operação de leitura maior que as de escrita; • O número de objetos replicados é reduzido; • Não exige alto desempenho para a utilização dos objetos; • Os meios de comunicação são de alto desempenho, confiáveis e de alta disponibilidade. Podemos citar como exemplos de sistemas que utilizam a estratégia de replicação síncrona sistema de aviação, bancário, comércio eletrônico e militar (MELO, 2010) 4.1.2 Replicação Assíncrona Nessa estratégia de replicação, as atualizações que ocorre no site não são propagadas instantaneamente para o site de destino, gerando uma latência nesse processa mento, pois as atualizações são registradas, enfileiradas e executadas nos objeto de destino em um segundo momento. A replicação assíncrona soluciona algumas limitações existentes na replicação síncrona, pois o tempo de resposta da transação é reduzido, entretanto a consistência dos dados é prejudicada, pois, a atualização é executada em apenas um local, desprezando a existência de outras réplicas. Essa estratégia de replicação pode ocorrer de duas formas, em lotes ou por demanda. Quando ocorre em lotes, as mudanças nos objetos são registradas e enfileiras para serem processadas em um momento posterior. Os critérios para a realização da sincronização entre objetos podem ser baseado em um período de tempo, na quantidade de transação acumuladas, etc. Quando a replicação ocorre por demanda, os objetos de destinos recebem as alterações quando a mesma é solicitada por uma aplicação (MELO, 2010). Algumas vantagens da replicação assíncrona são:
  33. 33. 33 ● Baixo custo de comunicação - a internet ou intranet pode ser utilizada para comunicação entre as réplicas. ● Aumento do desempenho das aplicações - inicialmente as operações são realizadas localmente, apresentando um tempo de resposta para as aplicações muito baixas, já que as mesmas podem utilizar objetos mais próximos. ● Menor concorrência - não há necessidade de bloquear recursos, pois as transações são executadas localmente. ● Maior disponibilidade - a possibilidade de uma operação não ser realizada é menor, pois o objeto não necessita que a comunicação com os demais esteja disponível. Esse tipo de replicação é utilizado quando não há necessidade dos dados serem atualizado em tempo real e quando os conflitos entre transações não acontecem com muita freqüência (MELO, 2010). 4.2 Modelos de Replicação Quanto ao modelo de replicação temos o modelo multimestre e o modelo mestre/escravo. 4.2.1 Modelo Mutimestre A replicação multimestre permite que vários sites gerenciem os grupos de objetos replicados de banco de dados, os aplicativos atualizam as tabelas replicadas em qualquer site pertencentes a esse modelo. Os servidores de banco de dados da que funcionam como site mestre em um ambiente multimestre converge os dados automaticamente de todas as réplicas de tabela garantindo a consistência global da transação de dados e a integridade dos dados. A replicação multimestre é útil para garantir a disponibilidade de um banco de dados de crítico de missão e também para os aplicativos de processamento de transação que necessitam de inúmeros pontos
  34. 34. 34 de acesso ás informações do banco de dados, garantindo a disponibilização de dados ou mais acesso localizado de dados (RAMALHO, 2005). Na figura 4 temos uma representação do modelo mutimestre. Figura 4 - Representação do modelo multimestre. Fonte: (http://prezi.com/axoc18nzbmtm/replicacao-de-dados/). 4.2.2 Modelo Mestre / Escravo Nesse modelo a replicação é unidirecional, ou seja, replicação ocorre somente em um sentido, de uma unidade primária de distribuição dos dados chamada de mestre para uma unidade secundária chamada de escravo, sendo que essa unidade pode ser fragmentada ou desfragmentada, centralizada ou distribuída. Esse modelo de replicação é normalmente utilizado em backup servidores de banco e na melhoria de desempenho de consultas em sites remotos, esse modelo também possibilita a rápida recuperação de dados no caso de indisponibilidade da unidade mestre. Apenas a base mestre recebe atualizações enquanto na base só é permitida a leitura (RAMOS, 2007).
  35. 35. 35 Na figura 5 temos uma representação do modelo mestre/escravo. Figura 5 - Representação do modelo mestre/escravo. Fonte: (http://prezi.com/axoc18nzbmtm/replicacao-de-dados/). 4.3 Objetos de Replicação Segundo Ramalho (2005) quando um objeto de banco de dados existe em vários servidores de um sistema de banco de dados distribuídos, ele é chamado de objeto de replicação. Alguns bancos de dados permitem replicar tabelas e objetos de suporte, tais como visões, triggers de banco de dados, packages, índices e sinônimos. 4.4 Conflitos de Replicação Segundo Ramalho (2005) é importante os ambientes de replicação prever a possibilidade de conflitos de replicação que podem ocorrer quando duas ou mais transações de originadas de sites distintos tentam atualizar a mesma informação praticamente no mesmo momento. Se ocorrer conflitos de dados é necessário ter mecanismos para garantir que os conflitos sejam sanados, conforme as regras de
  36. 36. 36 negócio e que os dados sejam tratados corretamente em todos os sites. Além dos conflitos que ocorrem em ambientes é importante ter recursos que permitam definir um sistema de resolução de conflitos.
  37. 37. 37 5 APLICAÇÃO Para o ambiente de replicação será utilizada os seguintes componentes: • VitualBox da Oracle para a criação de 2 máquinas virtuais; • Banco de Dados Oracle 10G; • Banco de Dados MySQL 5.0; • Conexão ODBC. Servidor Mestre Figura 6 - Maquina virtual que funcionará como servidor mestre. Fonte: Elaborado pelo autor.
  38. 38. 38 Servidor Escravo Figura 7 - Máquina virtual que funcionará como servidor escravo. Fonte: Elaborado pelo autor. O banco de dados Oracle 10g foi instalado no servidor (Mestre) e possui as tabelas funcionário e dependente sendo que somente a tabela de funcionário será replicada, conforme a figura 8.
  39. 39. 39 Figura 8 - Diagrama de Entidade de Relacionamento D.E.R Fonte: Elaborado pelo autor. Foi utilizado o seguinte código SQL para a criação das tabelas, conforme o diagrama anterior. CREATE DATABASE cadastro; USE cadastro; CREATE TABLE Dependente ( idDepen NUMBER (7,1) NOT NULL , Funcionario_idFunc NUMBER (7,1) NOT NULL , Nome VARCHAR2 (45) , Cpf VARCHAR2 (11) , Rg VARCHAR2 (10) ); ALTER TABLE DependenteADD CONSTRAINT Dependente_PK PRIMARY KEY ( idDepen );
  40. 40. 40 CREATE TABLE Funcionario ( idFunc NUMBER (7,1) NOT NULL , Nome VARCHAR2 (45) , Cpf VARCHAR2 (11) , Rg VARCHAR2 (10) , Cargo VARCHAR2 (45) ); ALTER TABLE Funcionario ADD CONSTRAINT Funcionario_PK PRIMARY KEY ( idFunc ); ALTER TABLE Dependente ADD CONSTRAINT Dependente_Funcionario_FK FOREIGN KEY ( Funcionario_idFunc ) REFERENCES Funcionario ( idFunc ) ; No servidor (Escravo) foi instalado o MySQL 5.0 será criada nesse banco de dados a tabela funcionario, que receberá os dados do servidor(Mestre), a seguir o código SQL utilizado para a criação da tabela. CREATE TABLE Funcionario ( idFunc INTEGER(7) UNSIGNED NOT NULL , nome VARCHAR(45) NULL, cpf VARCHAR(11) NULL, rg VARCHAR(10) NULL, cargo VARCHAR(45) NULL, PRIMARY KEY(idFunc) ); 5.1 Criação do Processo de Replicação Para a criação do processo de replicação, está sendo utilizadas duas bases de dados, sendo que a replicação ocorrerá da base de dados mestre (Oracle) para o
  41. 41. 41 escravo (MySQL) conforme a figura 9: Figura 9 - Representação do Esquema de Replicação Fonte: Elaborado pelo autor. Todas as operações realizadas no banco de dados da Oracle, será replicada para o banco de dados MySQL, combinando o modelo de replicação mestre/escravo com o tipo de replicação síncrona, pois todas as operações será replicada instantaneamente. A criação do processo de replicação se iniciou pela máquina mestre onde foi configurada a conexão ODBC, que permitirá a comunicação entre os bancos de dados Oracle e MySQL, conforme a figura a seguir:
  42. 42. 42 Figura 10 - Configurando ODBC MySQL Fonte: Elaborado pelo autor. No arquivo listener.ora que está localizado no diretório C:oraclexeapporacle product10.2.0serverNETWORKADMIN adicionamos o seguinte código no arquivo: (SID_DESC = (SID_NAME = ORACLE_MYSQL) (ORACLE_HOME = C:oraclexeapporacleproduct10.2.0server) (PROGRAM = hsodbc) ) Após a configuração do arquivo listener. ora, se faz necessário a configuração do arquivo tsnames.ora localizando no diretório C:oraclexeapporacleproduct 10.2.0serverNETWORKADMIN é inserido no arquivo o seguinte código: ORACLE_MYSQL =
  43. 43. 43 (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = servidor-9dd59b)(PORT = 1521)) (CONNECT_DATA = (SID=ORACLE_MYSQL) ) (HS=OK) ) Agora se faz necessário criar o arquivo unitORACLE_MYSQL.ora no diretório C:oraclexeapporacleproduct10.2.0serverhsadmin conforme a figura 11. Figura 11 - Criando o Arquivo Init Fonte: Elaborado pelo autor. O arquivo initORACLE_MYSQL.ora é composto pelo seguinte código:
  44. 44. 44 # This is a sample agent init file that contains the HS parameters that are # needed for an ODBC Agent. # # HS init parameters # HS_FDS_CONNECT_INFO = ORACLE_MYSQL HS_FDS_TRACE_LEVEL = 0 # # Environment variables required for the non-Oracle system # #set <envvar>=<value> Após a configuração do arquivo initORALCE_MYSQL.ora é necessário reiniciar o serviço do banco de dados para que as configurações sejam aplicadas ao banco de dados Oracle conforme a figura 12: Figura 12 - Reiniciando o Banco de Dados Oracle Fonte Elaborado pelo autor.
  45. 45. 45 Agora fazemos a conexão entre o banco de dados Oracle e MySQL, conforme o código SQL a seguir: CREATE DATABASE LINK "conMYSQL" CONNECT TO "user" IDENTIFIED BY "123456" USING 'ORACLE_MYSQL' Cada linha significa: Linha 1 – nome do link. Linha 2 – nome de usuário do banco MySQL. Linha 3 – senha usuário do banco MySQL. Linha 4 – o nome dado à conexão de fonte de dados ODBC do sistema. Após a criação da conexão entre os bancos de dados, criaremos os sinônimos para facilitar a manipulação das tabelas conforme o código SQL a seguir: CREATE SYNONYM funcionarioMYSQL FOR funcionario@con; CREATE SYNONYM dependentesMYSQL FOR dependente@con; Feito a criação dos sinônimos, vamos criar as procedures e triggers das tabelas funcionário e dependente. Criamos a procedure para inserção de dados na tabela funcionário, conforme o código SQL a seguir: create or replace PROCEDURE procINSERT(i NUMBER, n VARCHAR2, cp VARCHAR2, rg VARCHAR2, ca VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO funcionarioMYSQL VALUES(i,n, cp, rg,ca); COMMIT;
  46. 46. 46 END; Criamos a procedure para exclusão de dados na tabela funcionário, conforme o código SQL a seguir: create or replace PROCEDURE procDELETE(i NUMBER) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN DELETE FROM funcionarioMYSQL WHERE "idFunc" = i; COMMIT; END; Criamos a procedure para atualização de dados na tabela funcionário, conforme o código SQL a seguir: create or replace PROCEDURE procUPDATE(io NUMBER ,i NUMBER, n VARCHAR2, cp VARCHAR2, rg VARCHAR2, ca VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN UPDATE funcionarioMYSQL SET "idFunc"=i, "nome"=n, "cpf"=cp, "cargo"=ca WHERE "idFunc"=io; COMMIT; END; Agora vamos criar as trigger da tabela funcionários, começamos pela trigger que irá chamar a procedure procINSERT, conforme o código SQL a seguir. create or replace TRIGGER tgINSERT AFTER INSERT ON funcionario REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW
  47. 47. 47 BEGIN procINSERT(:NEW.idFunc, :NEW.nome, :NEW.cpf, :NEW.rg, :NEW.cargo); END; Agora vamos criar a trigger que irá chamar a procedure procDELETE, conforme o código SQL a seguir. create or replace TRIGGER tgDELETE AFTER DELETE ON funcionario REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN procDELETE(:OLD.idFunc); END; Criamos agora trigger que irá chamar a procedure procUPDATE, conforme o código SQL a seguir. create or replace TRIGGER tgUPDATE AFTER UPDATE ON funcionario REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN procUPDATE(:OLD.idFunc,:NEW.idFunc, :NEW.nome, :NEW.cpf, :NEW.rg, :NEW.cargo); END; Feito isso, vamos criar a procedures e trigger da tabela dependente, começando pela procedure responsável pela inserção de dados, conforme o código SQL a seguir: create or replace
  48. 48. 48 PROCEDURE procINSERTdepen(i NUMBER, ii NUMBER,n VARCHAR2, cp VARCHAR2,rg VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO dependenteMYSQL VALUES(i, ii, n,cp, rg); COMMIT; END; Criamos a procedure para exclusão de dados da tabela dependentes, conforme o código SQL a seguir: create or replace PROCEDURE procDELETEdepen(i NUMBER) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN DELETE FROM dependenteMYSQL WHERE "idDepen"= i; COMMIT; END; Criamos a procedure para atualização de dados da tabela dependente, conforme o código SQL a seguir: create or replace PROCEDURE procUPDATEdepen(io NUMBER, i NUMBER, ii NUMBER,n VARCHAR2, cp VARCHAR2,rg VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN UPDATE dependenteMYSQL SET "idDepen"=i, "Funcionario_idFunc"=ii, "nome"= n, "cpf"= cp, "rg"=rg WHERE "idDepen"=io; COMMIT; END; Concluída as procedures da tabela dependente, se faz necessário criar as trigger, começaremos pela trigger responsável por chamar a procedure procINSERTdepen,
  49. 49. 49 conforme o código SQL a seguir. create or replace TRIGGER tgINSERTdepen AFTER INSERT ON dependente REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN procINSERTdepen(:NEW.idDepen, :NEW.funcionario_IDFUNC, :NEW.nome, :NEW.cpf, :NEW.rg); END; Agora vamos criar a trigger que irá chamar a procedure procDELETEdepen, conforme o código SQL a seguir: create or replace TRIGGER tgDELETEdepen AFTER DELETE ON dependente REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN procDELETEdepen(:OLD.idDepen); END; Agora vamos criar a trigger que irá chamar a procedure procUPDATEdepen, conforme o código SQL a seguir: create or replace TRIGGER tgUPDATEdepen AFTER UPDATE ON dependente REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN procUPDATEdepen(:OLD.idDepen,:NEW.idDepen,:NEW.Funcionario_idFunc,
  50. 50. 50 :NEW.nome, :NEW.cpf, :NEW.rg); END; 5.2 Testes O teste de replicação será realizado na tabela de funcionário com as operações de inserção, atualização e exclusão de dados. Vamos realizar a inserção de 4 registros no banco de dados da Oracle e verificar se os dados foram replicados para a base de dados do MySQL. Figura 13 - Inserindo Dados no Banco de Dados da Oracle Fonte: Elaborado pelo autor.
  51. 51. 51 Como podemos ver de os dados foram replicados para o MySQL, conforme a figura 14: Figura 14 - Dados Replicados Para o MySQL Fonte: Elaborado pelo autor.
  52. 52. 52 Será realizada a atualização de um registro no banco de dados da Oracle conforme a figura 15: Figura 15 - Atualizando Dados no Banco de Dados da Oracle Fonte: Elaborado pelo autor.
  53. 53. 53 Podemos ver que a atualização também ocorreu no MySQL conforme a figura 16: Figura 16 - Dados Atualizados no MySQL Fonte: Elaborado pelo autor.
  54. 54. 54 Agora será realizada a exclusão de um registro no banco de dados da Oracle conforme a figura 17: Figura 17 - Excluído Um Registro no Banco de Dados da Oracle Fonte: Elaborado pelo autor.
  55. 55. 55 Como pode ser visto o registro foi excluído no banco de dados MySQL conforme a figura 18: Figura 18 - Registro Excluído no MySQL Fonte: Elaborado pelo autor.
  56. 56. 56 5.3 Considerações Conforme os testes realizados, pode-se observar que todas as operações realizadas no banco de dados da Oracle foram replicadas para o MySQL, como os testes foram realizados em máquinas virtuais não houve a necessidade de se implantar uma infraestrutura de comunicação para a transferência de dados. Neste trabalho apenas a tabela de funcionário foi replicada, contudo, para replicar outras tabelas, basta utilizar os mesmos princípios que foram explanados durante o desenvolvimento do ambiente de replicação, sendo possível utilizar outros bancos de dados e até mesmo combinar modelos e estratégias de replicações conforme a necessidade. A replicação síncrona foi utilizada para que fosse possível perceber as alterações nos ambientes, contudo, para essa estratégia de replicação é indispensável uma conexão entre os servidores com a maior disponibilidade possível. Entretanto quando não existe um meio de comunicação confiável a replicação assíncrona pode ser utilizada, porém, é importante salientar que pode ocorrer inconsistência e conflitos entre as réplicas. Quanto aos bancos de dados utilizados, não foi levado em consideração o desempenho, a segurança e outros fatores relativos aos mesmos, entretanto, ambos são muito utilizados no mercado.
  57. 57. 57 6 CONSIDERAÇÕES FINAIS Como foi visto a replicação de dados oferece muitas vantagens como desempenho, disponibilidade, redução de custos e distribuição de dados, já que é possível ter a mesma réplica armazenada em diversos servidores independente do software de banco de dados, porém é necessário levar em consideração o ambiente, a localização e principalmente a infra-estrutura disponível. Neste caso foi utilizada a replicação síncrona com o modelo mestre/escravo, para que fosse possível perceber a replicação de dados entre os bancos de dados heterogêneos. É importante salientar que ao utilizar a estratégia de replicação síncrona, o meio de comunicação tem que ser confiável e com alta disponibilidade, pois, o processo de replicação pode ser comprometido, contudo, com a replicação síncrona as bases de dados sempre estarão atualizadas. Foi possível esclarecer que existem estratégias e modelos de replicação para situações específicas, cabendo ao profissional da área verificar quais as combinações atende a situação desejada. A replicação de dados ainda precisa ser bastante explorada, pois é um assunto que ainda é pouco discutido atualmente. Durante o desenvolvimento deste trabalho foi possível comprovar que é possível implementar um banco de dados distribuído e replicá-lo para qualquer banco de dados independente do fabricante. O desenvolvimento do ambiente de replicação permitiu a demonstração de todo o processo de configuração e replicação, bem como aplicar os conceitos abordado neste trabalho, já que foi possível a junção da teoria com a prática, permitindo uma melhor compreensão e entendimento do conteúdo explanado.
  58. 58. 58 REFERÊNCIAS BOSS, Líbia. Replicação de Dados Disponível em: <http://prezi.com/axoc 18nzbmtm/ replicacao-de-dados/> Acesso em: 3 set, 2013 DATE, C. J. Introdução a Sistemas de Banco de Dados. 8º. ed. São Paulo: Elsevier Brasil, 2003, 864p. ELMASRI, R.; NAVATHE, S. B. Sistema de Banco de Dados. 6º. ed. São Paulo: PEARSON, 2011. 808p. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados. 3º. ed. São Paulo: Makron Books, 1999. 904p. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados. 5º. ed. Rio de Janeiro: Elsevier, 2006. 808p. MACIEL, Lucas. Conexão e replicação de dados em banco de dados distribuídos heterogêneos Disponível em: <http://imasters.com.br/banco-dedados/postgresql/ conexao-e-replicacao-de-dados-em-banco-de-dados-distribuidosheterogeneos-parte-01/> Acesso em: 21 ago, 2013 MATTOSO. BANCO DE DADOS DISTRIBUÍDOS Disponível em: <http://www.cos.uf rj.br/~marta/IntroductionP3.pdf> Acesso em: 17 mai, 2013 MELO, P. C. B. Desenvolvimento de um Sistema de Replicação. 2010. 105f. Manografia (Bacharelado em Engenharia da Computação) - UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE , Natal RN, 2010. ÖZSU, M. T.; VALDIUREZ, P. Principles of Distributed Database Systems. 3º. ed. New York: Springer, 2011. 860p. Disponível em: <http://dl.bookos.org/genesis/6040 00/7a0f200338289c2f7cbe5b7e165fa510/_as/[M._Tamer_%C3%96zsu,_Patrick_Val duriez]_Principles_of_(Bookos.org).pdf> Acesso em: 13 out, 2013 ORACLE.. Introdução à Replicação Avançada Disponível em: <http://docs.o racle.com/cd/B19306_01/server.102/b14226/repoverview.htm#REPLN001> Acesso em: 1 out, 2013
  59. 59. 59 RAMALHO, J. A. ORACLE 10G. 1º. ed. São Paulo: Thomson Pionera , 2005. 377p. RAMOS, Wagner. Replicação de Dados Disponível em: <object.com.br/file s/Replicação OBJECTSistemas.ppt> Acesso em: 6 ago, 2013 VIANA.. MYSQL: Replicação de Dados, Adriel Lucas Da Silva Viana Disponível em: <http://www.devmedia.com.br/mysql-replicacao-de-dados/22923> Acesso em: 28 out, 2013

×