UNIVERSIDADE COMUNITÁRIA REGIONAL DE CHAPECÓ
CENTRO TECNOLÓGICO
CURSO DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO
UM PROTÓTIPO DE BANCO DE DADOS
DISTRIBUÍDOS (CASO EXPRESSO SÃO MIGUEL)
CESAR ANTÔNIO BORTOLINI
CHAPECÓ (SC), NOVEMBRO DE 2004.
César Antonio Bortolini
UM PROTÓTIPO DE BANCO DE DADOS
DISTRIBUÍDOS (CASO EXPRESSO SÃO MIGUEL)
PROJETO APRESENTADO À UNIVERSIDADE COMUNITÁRIA REGIONAL
DE CHAPECÓ, PARA AVALIAÇÃO DO TCC, COMO PARTE DOS REQUISITOS À
OBTENÇÃO DO GRAU DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO
Orientador: Mônica Tissiani De Toni Pereira
CHAPECÓ (SC), NOVEMBRO DE 2004.
AGRADECIMENTOS
Tenho enorme prazer e satisfação de agradecer as pessoas que fizeram parte
de mais uma fase de minha vida. Por isso gostaria de começar meus agradecimentos
nesta ordem:
Aos meus pais pela oportunidade oferecida e a dedicação prestada desde o
inicio de minha caminhada.
A
minha namorada Camila Farias, pelo carinho, incentivo, compreensão e
apoio quando tive dificuldades.
Agradeço também aos meus colegas de graduação pela amizade e pelo apoio
durante todo esse período.
Aos professores pela dedicação e amizade durante os anos do curso, e em
especial a minha professora orientadora pela disposição compreensão e amizade
durante a realização deste trabalho.
E por fim a Deus por que sem ele eu não estaria aqui neste dia tão importante
da minha vida.
i
SUMÁRIO
LISTA DE FIGURAS ................................................................................................................... IV
LISTA DE ABREVIATURAS E SÍMBOLOS .............................................................................. VI
ABSTRACT ................................................................................................................................. IX
1
INTRODUÇÃO .................................................................................................................... 11
1.1 OBJETO DE ESTUDO .................................................................................................... 12
1.2 OBJETIVOS..................................................................................................................... 12
1.2.1
Gerais ............................................................................................................... 12
1.2.2
Específicos ...................................................................................................... 12
1.3 JUSTIFICATIVA E PROBLEMATIZAÇÃO...................................................................... 13
2
SISTEMAS DISTRIBUÍDOS............................................................................................... 14
2.1
2.2
2.3
2.4
2.5
ARQUITETURAS PARALELAS: ..................................................................................... 15
CARACTERÍSTICAS....................................................................................................... 16
TIPO DE SISTEMAS DISTRIBUÍDOS............................................................................ 17
ARQUITETURA DE SISTEMAS DISTRIBUÍDOS .......................................................... 18
COMUNICAÇÃO EM SISTEMAS DISTRIBUÍDOS........................................................ 20
2.5.1
Redes e Sistemas Distribuídos..................................................................... 21
2.6 RPC (REMOTE PROCEDURE CALL) ........................................................................... 23
3
REDES DE COMPUTADORES ......................................................................................... 25
3.1 TIPOS DE REDES .......................................................................................................... 25
3.2 PROTOCOLOS ............................................................................................................... 26
4
BANCO DE DADOS ........................................................................................................... 28
4.1 BANCO DE DADOS E SGDBS....................................................................................... 28
4.2 MODELO DE BANCO DE DADOS................................................................................. 31
4.2.1
Modelo Conceitual.......................................................................................... 32
4.2.2
O Modelo Entidade-Relacionamento ........................................................... 33
4.2.3
Entidades e conjuntos de entidades............................................................ 33
4.2.4
Relacionamento e conjuntos de relacionamentos..................................... 34
4.2.5
Atributos .......................................................................................................... 34
4.2.6
Cardinalidade .................................................................................................. 35
4.2.7
Modelo Lógico ................................................................................................ 36
4.2.8
Modelo Físico.................................................................................................. 37
4.2.9
Generalização e Especialização ................................................................... 37
4.3 O MODELO RELACIONAL ............................................................................................. 38
ii
5
Estrutura do banco de dados........................................................................ 39
4.3.2
Chaves ............................................................................................................. 39
4.3.3
Domínios.......................................................................................................... 40
ÁLGEBRA RELACIONAL.................................................................................................. 41
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
6
4.3.1
SELEÇÃO ........................................................................................................................ 41
PROJEÇÃO ..................................................................................................................... 42
PROJEÇÃO E SELEÇÃO ............................................................................................... 42
OPERAÇÃO DE UNIÃO.................................................................................................. 43
DIFERENÇA .................................................................................................................... 43
INTERSECÇÃO............................................................................................................... 43
JUNÇÃO .......................................................................................................................... 44
PRODUTO CARTESIANO.............................................................................................. 44
DIVISÃO .......................................................................................................................... 44
SISTEMA DE BANCO DE DADOS DISTRIBUÍDOS ........................................................ 46
6.1 CARACTERÍSTICAS DE SBDDS................................................................................... 49
6.1.1
Gerenciamento transparente de dados Distribuídos................................ 49
6.1.2
Confiabilidade em transações distribuídas................................................. 51
6.1.3
Desempenho otimizado ................................................................................. 52
6.1.4
Expansão de sistemas mais fácil ................................................................. 52
6.2 PROBLEMAS E DIFICULDADES DA DISTRIBUIÇÃO DE BANCO DE DADOS ......... 53
6.3 RECUPERAÇÃO............................................................................................................. 54
6.3.1
Controle de Transações e Recuperação ..................................................... 54
6.3.2
Arquivos de Log ............................................................................................. 55
6.3.3
Ponto de checagem........................................................................................ 56
6.4 CAUSAS DE FALHAS..................................................................................................... 57
6.4.1
Falha do local da transação .......................................................................... 57
6.4.2
Falhas em sites ............................................................................................... 58
6.4.3
Falhas de mídia............................................................................................... 58
6.4.4
Falhas na rede de comunicação................................................................... 58
6.5 PROTOCOLOS DE EFETIVAÇÃO................................................................................. 59
6.5.1
Protocolo de efetivação em duas fases (2PC) ............................................ 59
6.5.2
7
Protocolo de efetivação em três fases (3PC).............................................. 60
ARQUITETURA DE SGBDS DISTRIBUÍDOS................................................................... 62
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
AUTONOMIA ................................................................................................................... 62
DISTRIBUIÇÃO ............................................................................................................... 63
HETEROGENEIDADE .................................................................................................... 63
SISTEMA CLIENTE-SERVIDOR .................................................................................... 64
SISTEMAS DISTRIBUÍDOS NÃO HIERÁRQUICOS ..................................................... 65
PROJETO DE BANCO DE DADOS DISTRIBUÍDO....................................................... 66
FRAGMENTAÇÃO HORIZONTAL ................................................................................. 69
FRAGMENTAÇÃO VERTICAL ....................................................................................... 72
FRAGMENTAÇÃO HÍBRIDA .......................................................................................... 73
iii
7.10
8
REGRAS DE FRAGMENTAÇÃO ............................................................................ 74
REPLICAÇÃO..................................................................................................................... 76
8.1 REPLICAÇÃO DE DADOS SÍNCRONA......................................................................... 77
8.2 REPLICAÇÃO DE DADOS ASSÍNCRONA.................................................................... 77
8.3 ATUALIZAÇÃO DAS RÉPLICAS .................................................................................... 78
8.3.1
Modelo mestre/escravo.................................................................................. 78
8.3.2
9
Modelo update-anywhere .............................................................................. 78
INTERBASE........................................................................................................................ 81
9.1 IBREPLICATOR .............................................................................................................. 82
9.2 CONFIGURAÇÃO ........................................................................................................... 83
9.2.1
Características adicionais ............................................................................. 84
10
PROTÓTIPO.................................................................................................................... 86
10.1
10.2
10.3
10.4
10.5
10.6
10.7
CONTEXTUALIZAÇÃO DO AMBIENTE................................................................. 86
POR QUE DA DISTRIBUIÇÃO ............................................................................... 86
CRITÉRIOS USADOS PARA FRAGMENTAÇÃO .................................................. 87
PROJETO GLOBAL................................................................................................. 89
PROJETOS LOCAIS ............................................................................................... 89
CONFIGURAÇÃO DA REPLICAÇÃO..................................................................... 89
SOBRE O SISTEMA................................................................................................ 96
11
CONCLUSÃO.................................................................................................................. 98
12
TRABALHOS FUTUROS ............................................................................................... 99
13
REFERÊNCIAS............................................................................................................. 100
14
ANEXOS........................................................................................................................ 102
iv
LISTA DE FIGURAS
Figura 1. Modelo arquitetura de acesso remoto ........................................................................ 18
Figura 2. Arquitetura Cliente-Servidor........................................................................................ 19
Figura 3. Arquitetura cliente-servidor em três camadas ............................................................ 20
Figura 4. Comunicação Cliente Servidor(TANENBUM,1995) .................................................. 22
Figura 6. Modelo OSI.................................................................................................................. 26
Figura 7. Modelo TCP/IP ............................................................................................................ 27
Figura 8. Um Sistema de Banco de Dados................................................................................ 29
Figura 9. Modelo entidade-relacionamento................................................................................ 32
Figura 10. Representação de como uma entidade é especificada em um DER ...................... 34
Figura 11. Representação de um relacionamento..................................................................... 34
Figura 12. Representação de atributos ...................................................................................... 35
Figura 13. Representação de cardinalidade um para um.......................................................... 35
Figura 14. Representação de cardinalidade um para muitos .................................................... 36
Figura 15. Representação de cardinalidade muitos para muitos .............................................. 36
Figura 16. Modelo Lógico ........................................................................................................... 37
Figura 17. Exemplo de Generalização ....................................................................................... 38
Figura 18. Arquitetura de um SGBDD homogêneo (DISTRIBUTED DATABASE SYSTEMS,
p.46) ............................................................................................................................................ 47
Figura 19. Exemplo de um Sistema de Banco de Dados Distribuídos(OZSU; VALDURIEZ,
2001, p.8) .................................................................................................................................... 48
Figura 20(a). Classificação para transação usando pontos de checagem assíncrono ........... 56
v
Figura 20(b). Classificação para transação usando pontos de checagem síncrono. ............... 56
Figura 21. Arquitetura cliente/servidor........................................................................................ 64
Figura 22. Arquitetura servidor/servidor ..................................................................................... 65
Figura 23. Processo do projeto top-down (ÖZSU; VALDURIEZ,2001)..................................... 68
Figura 24. Base de Dados de exemplo de fragmentação horizontal ........................................ 69
Figura 25. Exemplo Fragmentação horizontal ........................................................................... 70
Figura 26. Exemplo de fragmentação horizontal derivada ........................................................ 71
Figura 27. Exemplo de fragmentação vertical............................................................................ 72
Figura 28. Representação fragmentação horizontal.................................................................. 72
Figura 29. Representação fragmentação horizontal.................................................................. 73
Figura 30. Fragmentação híbrida ............................................................................................... 74
Figura 31. Tabela exemplo de fragmentação horizontal ........................................................... 88
Figura 32. Tela de configuração de Base de Dados.................................................................. 90
Figura 33. Base de dados configuradas.................................................................................... 91
Figura 34. Criando um esquema de replicação ......................................................................... 92
Figura 35. Tela de configuração da base de dados de origem ................................................. 93
Figura 36. Tela de definição do esquema de replicação ........................................................... 94
Figura 37. Definição da replicação ............................................................................................. 95
Figura 38. Configuração do intervalo de replicação .................................................................. 96
vi
LISTA DE ABREVIATURAS E SÍMBOLOS
Junção
Junção Externa a Direita
Junção Externa a Esquerda
Semijunção
−
Diferença
÷
Divisão
∩
Intersecção
∪
União
×
Produto Cartesiano
σ
Seleção
π
Projeção
ANSI
AMERICAN NATIONAL STANDARDS INSTITUTE
BD
Banco de Dados
BDD
Banco de Dados Distribuídos
DBA
DATABASE ADMINISTRATOR
DER
Diagrama Entidade Relacionamento
ER
Entidade Relacionamento
IP
Internet Protocol
ISO
INTERNATIONAL STANDARDS ORGANIZATION
SGBD
Sistema Gerenciador De Banco De Dados
vii
SGBDD Sistema Gerenciado de Banco de Dados Destruído
SQL
Struct Query Language
TCP
Transmission Control Protocol
UPD
User Datagram Protocol
viii
RESUMO
O presente trabalho apresenta fundamentos de banco de dados, redes de
computadores, sistema distribuídos e sistema de banco de dados distribuídos com
intuito de desenvolvimento de um protótipo de distribuição e replicação de banco de
dados aplicado ao estudado de caso de uma transportadora. A fim de validar a
pesquisa realizada neste trabalho, será desenvolvido um protótipo aplicando as
técnicas de distribuição e replicação. O estudo de caso na empresa Expresso São
Miguel teve inicio com a necessidade de um sistema distribuído com suporte a
replicação de maneira segura e confiável. A proposta de elaboração de um protótipo
de um sistema de banco de dados distribuído utilizando o sistema gerenciador de
banco de dados (SGBD) Interbase e uma ferramenta de suporte a replicação
IBReplicator. São apresentados neste trabalho as técnica de fragmentação e
alocação de dados utilizadas no protótipo e quais os passos utilizados na replicação
dos dados. Com a aplicação deste trabalho pretende-se aplicar algumas técnicas para
distribuição, alocação e replicação de dados ao longo de uma rede de computadores,
propondo uma solução para a transportadora e deixando uma referencia a trabalhos
futuros.
Palavras-chave: bancos de dados distribuídos, SGBDs, distribuição e fragmentação de dados,
replicação.
ix
ABSTRACT
The following work presents fundaments from databases, computer networks,
distributed systems and databases distributed system with aiming to develop a database
replication and distribution prototype applied to the case study of a transportation company. In
order to validate the research carried through in this work, an archetype will be developed
applying the techniques of distribution and replication. The case study began with the necessity
of a distributed system supporting replication in a secure and trustable manner. The
elaboration proposal of a distributed database system prototype using databases managing
system Interbase (SGBD) and a replication support tool IBReplicator. It is presented in this
work the fragmentation techniques and data allocation used in the prototype and the steps
used in the data replication. With the application of this work, it is intended to apply a few
techniques to distribution, allocation and replication of data throughout a computer network,
proposing a solution for the transportation company and leaving a reference for future works.
Key-words: distributed database, SGBDs, data distribution and fragmentation, replication.
1
INTRODUÇÃO
A evolução da informática e das companhias de telecomunicação nos proporcionam
uma enorme facilidade na comunicação e na transferência de informações. Com esse avanço
e com a capacidade dos sistemas gerenciadores de banco de dados controlarem várias
transações ao mesmo tempo, muitas empresas estão cada vez mais interessadas em ter
controle das informações de maneira centralizada. Porém, os dados podem ser mantidos em
locais diferentes.
No caso desse trabalho, serão estudadas técnicas para fragmentação e alocação de
dados em um sistema de banco de dados distribuído.
Atualmente, a disponibilidade dos dados pode fazer a diferença em uma empresa, ou
seja, no caso de uma transportadora onde a tendência é que se tenha uma descentralização
das unidades de trabalho em locais geograficamente distantes, podendo ser no perímetro de
uma cidade, de um estado ou até mesmo em países diferentes.
Os dados ficam distribuídos, sendo que, cada unidade possui um conjunto de dados
específicos, que podem ser consultados e alterados a qualquer momento para se obter
informações tanto de cunho gerencial quanto administrativo ou para tomada de decisão e
planejamento de metas. Além disso, cada unidade pode acessar informações de outras
unidades ou em um conjunto global de informações, por exemplo, o cadastro de um cliente.
Com esta disponibilidade pode-se ter acesso a informações com maior facilidade e
rapidez, aumentando assim a satisfação do cliente e conseqüentemente à lucratividade da
empresa.
Este trabalho tem como objetivo pesquisar e estudar a distribuição de dados utilizando
técnicas de fragmentação e alocação. Onde alterações feitas no banco de dados original ou
no banco de dados de destino, podem ser atualizadas em conjunto, dispondo de ferramentas
de alta tecnologia e com baixo custo.
O desenvolvimento deste trabalho pretende apresentar resultados efetivos para o
ambiente onde será aplicado o protótipo, fazendo uso de tecnologias recentes. Além disso,
técnicas que envolvam essas tecnologias são pouco utilizadas, principalmente na região
Oeste de Santa Catarina.
Este trabalho está dividido em sete capítulos: o primeiro fala sobre sistemas
distribuídos; o segundo sobre redes de computadores; já o terceiro ressalta o que é banco de
12
dados e os sistemas gerenciadores de banco de dados; o quarto descreve os sistemas de
bancos de dados distribuídos; o quinto explica as arquiteturas de banco de dados distribuídos;
no capítulo seis é apresentado um modelo de projeto de banco de dados distribuídos e o
capítulo sete descreve algumas características e técnicas de replicação de banco de dados.
1.1
OBJETO DE ESTUDO
Levantamento das principais tecnologias de distribuição e replicação de dados em
sistemas de Banco de Dados Distribuídos, especialmente no Sistema Gerenciador de Banco
de Dados (SGBD) Interbase, de tal forma a compreender qual dessas tecnologias aplica-se à
implementação de um banco de dados distribuído para uma transportadora de cargas.
1.2
OBJETIVOS
1.2.1 Gerais
Pesquisar metodologias e técnicas computacionais para sistemas de banco de dados
distribuídos e replicados, visando à modelagem conceitual de banco de dados distribuídos
bem como a construção de um protótipo aplicado à transportadora de cargas e encomendas.
1.2.2 Específicos
•
Levantamento bibliográfico sobre banco de dados, banco de dados distribuídos e sistemas
gerenciadores de bancos de dados distribuídos, sistemas distribuídos e redes de
computadores, visando embasamento teórico necessário ao desenvolvimento do protótipo
proposto.
•
Pesquisar métodos computacionais aplicados à distribuição de dados.
•
Pesquisar métodos computacionais aplicados à replicação de dados.
13
1.3
JUSTIFICATIVA E PROBLEMATIZAÇÃO
Tendo em vista que a empresa, objeto deste estudo, é uma transportadora que atua
em toda a região sul do país. Cada filial tem um banco de dados local que deve ser replicado
para um único banco de dados central. Diante disso, pode-se dizer que é de suma importância
o uso de uma tecnologia confiável para a distribuição e replicação dos dados.
Existe, na atualidade, a necessidade da disponibilização diária dos dados para todas
as filiais, pois através desta integração torna-se possível à entrega das encomendas com
maior agilidade, sendo nos dias de hoje um grande diferencial para empresas do ramo de
transportes.
Atualmente a empresa utiliza-se de um método de replicação import/export em
arquivos texto, este método atende as necessidades básicas da empresa, porém oferece
pouca segurança, deixando a empresa vulnerável e comprometendo assim seu crescimento.
Com a utilização de um banco de dados com suporte na distribuição e com a utilização
de técnicas de fragmentação e alocação de dados, propõe-se a implementação de um
protótipo na empresa, buscando adquirir uma performance desejável e um nível de segurança
adequado.
Os procedimentos metodológicos aplicados no projeto em questão serão: pesquisa em
livros que abordem o tema escolhido, artigos publicados, sites da internet relacionados ao
assunto e com a empresa que representa o banco de dados utilizado. Também busca-se
compreender o sistema computadorizado já existente na empresa e projetar a distribuição e
implementação do protótipo.
2
SISTEMAS DISTRIBUÍDOS
Os primeiros computadores produzidos para uso comercial, tinham uma estrutura
padrão baseada em processador, memória e armazenamento de dados. Devido ao alto custo
dos componentes na época, as capacidades de memória e de discos destes equipamentos
conhecidos como mainframe, eram mínimas se comparadas com equipamentos atuais. Na
evolução têm-se os minicomputadores, os microcomputadores, os computadores pessoais ou
PCs e a interligação dos equipamentos em rede. Essa interligação das máquinas em redes
propiciou o surgimento do conceito de sistemas distribuídos, aproveitando o potencial das
máquinas interligadas.
Um sistema distribuído proporciona ao usuário a impressão de que o software esta
completamente independente e que o hardware são computadores independentes. Isso
somente é possível graças a um conjunto de hardware e software preparados para a interação
de programas, que significa a adaptação tanto por parte do sistema operacional que é capaz
de operar sobre varias máquinas, tanto por parte das máquinas capazes de se comunicar
entre si (VERÍSSIMO;RODRIGUES,2001).
Um Sistema Distribuído é uma coleção de computadores autônomos, ligados
por uma rede, com software projetado para produzir uma facilidade de
computação integrada. (COULORIS;DOLLIMARE;KINDBERG, 2001,p 65)
Pode-se dizer que o hardware deve possuir uma infra-estrutura capaz de
desempenhar o papel de coordenação na comunicação dos programas paralelos, isso para
evitar eventuais problemas relacionados à heterogeneidade das máquinas. Com tudo faz-se
necessário à criação de um protocolo de comunicação para traduzir as diferentes linguagens
faladas.
Do mesmo modo, o software deve possuir uma infra-estrutura diferente, em que o
sistema operacional deve ser capaz de transformar seus mecanismos de gerenciamento
convencional em um mecanismo que opere em várias máquinas. Isso tudo para tornar o
paralelismo transparente para o usuário, ou seja, se o usuário solicitar um processo o mesmo
pode ser executado em qualquer uma das máquinas de uma rede de computadores sem que
o usuário perceba.
15
Os sistemas distribuídos possuem um ambiente de memória compartilhada e podem
se valer desta memória para ativar os processos paralelos através da utilização de troca de
mensagens para comunicação e sincronização das tarefas (FRIEDRICH, 2000,p66).
Segundo Friedrich (2000), há dois tipos principais de troca de mensagem:
PVM – Parallel Virtual Machine: é o conjunto integrado de bibliotecas e de ferramentas
de software, cuja finalidade é emular um sistema computacional concorrente, heterogêneo,
flexível e de propósito geral.
MPI – Message Passing Interface: Padrão de interface de troca de mensagens para
aplicações que utilizam computadores com arquitetura formada por processadores que
executam instruções independentemente com memória distribuída.
2.1
ARQUITETURAS PARALELAS:
Para Friedrich (2000) a classificação de Flynn é a mais utilizada embora não seja
muito abrangente:
•
SISD (Single Instruction Single Data):computadores com um único processador.
•
SIMD (Single Instruction Multiple Data): Computadores vetoriais, refere-se a um conjunto
(array) de processadores.
•
MISD (Multiple Instruction Single Data): O mesmo fluxo de dados percorre um array linear
de processadores.
•
MIMD (Multiple Instruction Multiple Data): A arquitetura formada por processadores que
executam instruções independentemente.
Já para Özsu(2001), outra dimensão de sistema de computação distribuída, é
classificada em dois tipos:
16
•
Sistemas fortemente acoplados: caracteriza-se pela existência de uma única memória
para todo o sistema que é compartilhado por todos os processadores. A comunicação
neste tipo de sistema é feita através de memória compartilhada.
•
Sistemas fracamente acoplados: neste tipo de sistema cada processador possui sua
memória local e a comunicação entre eles é feita através da passagem de mensagem por
uma rede de interconexão.
2.2
CARACTERÍSTICAS
Algumas características desses sistemas ou aplicações são (TANEMBAUM &
MARTEN VAN STEEN, 2002):
•
ESCOPO GEOGRÁFICO: diz respeito à disposição geográfica em que as máquinas
estarão fisicamente localizadas podendo ser em um mesmo escritório, na mesma cidade,
em outras cidades, estados e países.
•
HETEROGENEIDADE: são as diferentes configurações de hardware e software é um dos
principais problemas em um projeto de sistema distribuídos. Pode-se encontrar diversos
tipos de arquitetura de hardware em diversos tipos de software de gerenciamento.
•
MODULARIDADE: a modularidade diz respeito à integração entre os diversos sistemas
que poderão estar sendo utilizados na mesma rede de computadores e a capacidade de
interação entre os mesmos.
•
COMPARTILHAMENTO: a capacidade de compartilhamento dos sistemas distribuídos
deve ser alta e bem projetada para que todos os sistemas possam ter a sua disposição os
serviços necessários.
•
SEGURANÇA: como os dados estão disponíveis em várias máquinas, os dados secretos
também são acessíveis facilmente. Isto significa que ficaria fácil acessar dados que em
tese não deveriam ser acessados.
•
ESCALABILIDADE: um sistema distribuído está sujeito a um grande crescimento, e com
isso aumenta a probabilidade de ocorrerem
falhas. Com o aumento do número de
máquinas na rede, o grande desafio é o projeto de software de sistema distribuído, que
17
deve ser proporcional ao crescimento. O requisito principal é projetar serviços distribuídos
que continuem operando de maneira efetiva com centenas ou milhares de clientes.
•
CONCORRÊNCIA: ocorre quando dois ou mais processos começaram sua execução,
mas não terminaram. A concorrência em sistemas distribuídos ocorre a todo o momento
devido às atividades separadas dos usuários, a independência
dos recursos e a
localização de servidores em máquinas separadas.
•
ISOLAMENTO: é a capacidade que tem uma transação de não intervir em outras
transações que estejam sendo realizadas ao mesmo tempo.
2.3
TIPO DE SISTEMAS DISTRIBUÍDOS
Alguns tipos de Sistemas distribuídos são (ÖZSU; VALDURIEZ, 2001):
•
Serviços de nomes : são componentes da computação distribuída onde os usuários e
programas podem localizar pessoas, lugares, aplicações e serviços em ambientes
distribuídos.
•
Serviços de registros, autorização, autenticação: são os serviços de gerenciamento e de
controle da internet por exemplo a AT&T,PSI e General Atomics, que organizam a
distribuição dos endereços e registros de domínios e também das RFC’s.
•
Serviços de Rede: são serviços voltados a redes de computadores,
por exemplo, o
Classical IP que ocorre de modo nativo e também o serviço LANE - LAN Emulation. Outro
exemplo muito utilizado é o Sockets que implementa os protocolos TCP/IP. É um conjunto
de chamadas possíveis a bibliotecas que contém rotinas implementando determinados
objetivos.
•
Serviços de Tempo: como um sistema distribuído é um conjunto de computadores
conectados por meio de uma rede de comunicação onde não há compartilhamento de um
relógio comum. Existem uma necessidade de se tratar o tempo, para isso, usam-se alguns
serviços, como:
•
Tempo Universal Coordenado (UTC)
18
2.4
•
Algoritmos de Sincronização de Relógios
•
NTP: Network Time Protocol
•
Relógios Lógicos
•
Representações e Serviços de Tempo: Unix e CORBA
ARQUITETURA DE SISTEMAS DISTRIBUÍDOS
•
Acesso Remoto
•
Arquitetura Cliente/Servidor
•
Arquitetura Cliente/Servidor em 3 camadas
•
Arquitetura de Site Móvel
Acesso remoto: é uma das formas primordiais de distribuição e visa distribuir acesso
remoto a facilidades centralizadas, como sessão remota e transferência de arquivos.
Site 1
Site 2
Site 3
Figura 1. Modelo arquitetura de acesso remoto.
Um exemplo de acesso remoto são os terminais burros onde o processamento é feito
todo no servidor e apenas os dados são acessados remotamente.
19
Arquitetura Cliente/Servidor: Onde os serviços residem em servidores centrais, mas as
estações são independentes para rodar aplicativos e executar alguns dos processos
localmente, minimizando a grande carga do servidor.
Figura 2. Arquitetura Cliente-Servidor1.
Arquitetura Cliente/Servidor em três camadas: um passo a frente da arquitetura
cliente/servidor a arquitetura cliente/servidor em três camadas proporciona uma camada
intermediária entre a interface e o banco de dados. Essa camada também é chamada de
servidor de aplicação que é uma espécie de gerente de transações, é por onde todas as
requisições ao banco de dados devem passar.
1
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp, 2004,23:40
20
Figura 3. Arquitetura cliente-servidor em três camadas2
A arquitetura em três camadas se caracteriza pela camada intermediária entre a
aplicação e o banco de dados, esta camada é chamada de servidor de aplicação. Pois é uma
espécie de gerente da aplicação, é neste servidor de aplicação que se aplicam às regras de
transação e a lógica do negócio. A camada cliente é a camada que trata da interface com o
usuário, ou seja, nela podemos encontrar apenas algumas regras ou procedimentos
específicos de cada aplicação. E o banco de dados é a última camada e também onde os
dados são armazenados para possíveis acessos de alteração ou consulta.
Arquitetura de Site Móvel: são sites clientes ou servidor, se movem de um lugar a outro
da rede, e apenas off-line, ou seja, desligados como, por exemplo, notebooks e PDAs. Este
tipo de arquitetura é muito encontrado em sistema de representantes comercias e
vendedores.
2.5
COMUNICAÇÃO EM SISTEMAS DISTRIBUÍDOS
Nos sistemas distribuídos os componentes estão logicamente e fisicamente
separados, mas precisam se comunicar para interagir. Podemos dizer que os componentes
que fornecem e requerem acesso a recursos são implementados como processos, e a
comunicação entre eles envolve operações tanto no processo que envia como no processo
2
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp,2004,23:40
21
que recebe. Para que esta comunicação seja possível estes processos precisam de regras
como protocolo de comunicação, primitivas de comunicação e modelos de comunicação
(OZSU; VALDURIEZ, 2001).
2.5.1 Redes e Sistemas Distribuídos
Algumas das facilidades de rede que podem ser implementadas em sistemas
distribuídos são exploradas através de componentes de hardware (switches, interfaces) e de
software (protocolos e tratadores) e esta coleção pode ser chamada de subsistema de
comunicação. Alguns fatores que influenciam para um bom projeto de subsistema de
comunicação são:
a) Os Parâmetros de performance que influenciam na velocidade de transferência das
mensagens como latência e a taxa de transferência:
Latência: é o tempo que uma mensagem vazia leva para ser transmitida, ou
seja, é os retardos de software para acessar a rede.
Taxa de transferência: velocidade de transferência dos dados entre
computadores da rede.
b) Requisitos de performance: referem-se ao tempo de acesso a arquivos, em uma
arquitetura cliente servidor adiciona-se ainda o tempo de envio da requisição e a recepção
da resposta. Este tempo não deveria ser maior que o tempo de acesso ao disco. Esta
performance é conseguida com latência menor que 5 mili-segundos e taxa de
transferência maior que 200 Kbytes por segundo.
c) Requisitos de confiabilidade: este tipo de requisito é necessário à maioria das aplicações
de sistemas distribuídos. Grande parte dos erros que ocorrem são devidos à falhas de
temporizacão do software na transmissão e recepção do que na rede por causa dos
protocolos de controle (TANEMBAUN,1997).
22
2.5.1.1 Comunicação Cliente Servidor
Segundo Tanenbaum (1995), uma das estruturas mais comuns para os sistemas
distribuídos é a do cliente-servidor. A principal idéia deste modelo é estruturar o sistema
operacional como um grupo de processos cooperantes, denominados servidores, que
oferecem serviços a processos usuários, denominados clientes. As máquinas clientes e
máquinas servidoras normalmente rodam o mesmo microkernel, onde tanto os clientes quanto
os servidores rodam como processos usuários. Uma única máquina pode estar rodando um
processo, vários clientes, vários servidores, ou uma mistura dos dois.
Figura 4. Comunicação Cliente Servidor(TANENBUM,1995)
O modelo cliente/servidor é baseado em um protocolo muito simples, sem conexão, do
tipo solicitação/resposta, de tal forma a evitar overhead dos protocolos orientado a conexão,
tal como o OSI ou o TCP/IP, com a vantagem da simplicidade, onde o cliente envia uma
solicitação ao servidor e recebe dele uma resposta. Nenhum tipo de conexão deve ser
estabelecido antes do envio da solicitação, nem desfeito após a obtenção da resposta. A
própria mensagem de resposta serve como uma confirmação do recebimento da solicitação.
Devido a esta estrutura extremamente simples, os serviços de comunicação fornecidos pelo
microkernel podem, por exemplo, ser reduzidos a duas chamadas de sistema, uma para envio
de mensagens e outra para a recepção das mesmas.
23
2.6
RPC (REMOTE PROCEDURE CALL)
RPC (Remote Procedure Call) é um método comum e largamente aceito para o
encapsulamento de mensagens em um sistema distribuído. A essência desta técnica é
permitir que programas em diferentes máquinas possam interagir usando simples semântica
de procedimentos call/return, ou seja, é como se os dois programas estivessem na mesma
máquina(STALLINGS, 1998).
Segundo Kindberg(2001), este tipo de comunicação é bastante aceito pelas seguintes
características:
•
A chamada de um procedimento é amplamente aceita, usada e de abstração entendida.
•
O uso de chamadas remotas de procedimentos permite que interfaces remotas sejam
designadas como um conjunto de operações nomeadas com tipos designados. Assim esta
interface pode ser claramente documentada e os programas distribuídos podem ser
conferidos estaticamente, em tempo de compilação, para validar os erros de tipos (permite
conferir os tipos de dados que estão sendo usados nas chamadas, em tempo de
compilação)
•
Devido à especificação de uma interface padronizada e precisa, o código de comunicação
para uma aplicação pode ser gerado automaticamente.
•
Devido à especificação de uma interface padronizada e precisa o programador pode
escrever módulos clientes e módulos servidores que podem ser usados em diferentes
computadores
recodificação.
e
sistemas
operacionais
com
pequenas
modificações
e
pouca
24
Figura 5. Representação do mecanismo de RCP (GALLI,1998)
Já para Friedrich (2000), a principal meta do mecanismo de chamada remota de
procedimento é o de manter o máximo possível à semântica da chamada de procedimento
convencional em um ambiente de implementação totalmente diferente, ou seja, em um RPC
os parâmetros de entrada são enviados para o servidor através da passagem de mensagem e
os parâmetros de saída são enviados ao cliente na mensagem de resposta. Tudo isso só é
possível graças à tecnologia de redes computadores.
3
REDES DE COMPUTADORES
Para Tanenbaum (1997,p.16), “uma rede de computadores é como uma coleção de
computadores autônomos interconectados que são capazes de trocar informações entre si ”.
Os sistemas são ditos como autônomos por razão de que cada máquina deve ser
capaz de executar programas isoladamente, desde que as máquinas estejam interconectadas,
para que essas sejam capazes de trocar informações.
Em banco de dados distribuídos as redes são o suporte básico para que se tenha
comunicação de dados, sem rede não haverá comunicação, e sem comunicação não tem por
que fazer distribuição de dados.
3.1
TIPOS DE REDES
Redes locais (LAN): as redes locais (LANs), são redes de pequena dimensão que
interligam computadores e dispositivos periféricos de um mesmo estabelecimento e possuem
uma pequena extensão geralmente inferior a 10 kilometros. As taxas de transferência podem
variar entre 0.2 ate 100 Mbps.
Redes metropolitanas(MAN): as redes metropolitanas (MANs) são redes de dimensão
média aproximadamente o espaço de uma cidade constituídas por duas ou mais redes locais.
Este tipo de rede é comum em instituições como universidades, hospitais ou em delegações
espalhadas ao longo de uma cidade. Exemplos típicos de instituições que utilizam este tipo de
rede são os bancos, as grandes empresas nacionais e multinacionais e as instituições de
âmbito científico.
Redes de longa distancia(WAN): as redes de longa distância são redes de grande
dimensão com abrangência nacional ou até mesmo internacional.Este tipo de rede é
composta por outras redes e computadores isolados e são normalmente interligadas por
agentes de telecomunicação (TANEMBAUM,1997).
26
3.2
PROTOCOLOS
Não basta apenas ligar fisicamente dois ou mais computadores para que eles se
comuniquem, mas para que se tenha uma comunicação confiável e segura necessita-se de
um sistema de software que irá definir algumas regras para a comunicação entre os
computadores. Estes sistemas são chamados de protocolos de comunicação. A complexidade
desses protocolos difere entre as redes remotas, locais e metropolitanas (OZSU; VALDURIEZ,
2001).
Figura 6. Modelo OSI3
Podemos dizer que as WANs por serem redes de longa distância e por terem que
acomodar diversos tipos de equipamentos e conexões, que às vezes possuem diferentes
velocidades e até mesmo tamanhos de palavras, tem uma maior necessidade de protocolos
de comunicação. Exemplo deste tipo de protocolo e mais conhecido se baseia na arquitetura
3
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp,2004,23:40
27
de interconexão de sistemas abertos da Internation Stadards Organization(OSI) na figura
acima. Este modelo diz que a rede deve ser construída em camadas, e entre estas camadas
devem ser definidas as interfaces que facilitam a passagem de informação entre o software e
o hardware. Este modelo é composto por sete camadas sendo elas a camada física, a
camada de link de dados, a camada de rede, a camada de transporte, a camada de sessão, a
camada de apresentação e a camada de aplicação. Mais detalhes sobre as camadas do
modelo OSI pode-se encontrar em (TANEMBAUM,1997).
Outro modelo de protocolo utilizado em WANs é o TCP/IP, que segue a mesma idéia
do modelo OSI, porém este modelo possui apenas quatro camadas.
Figura 7. Modelo TCP/IP
O modelo representado na figura acima, apresenta apenas quadro camadas, porém
seguem o mesmo padrão de referencia do modelo OSI.
Pode-se dizer que para composição de um sistema de banco de dados distribuídos
também é necessário que se apresente os conceitos que seguem.
4
BANCO DE DADOS
4.1
BANCO DE DADOS E SGDBS
Existem vários conceitos sobre banco de dados. Resumidamente podemos entender
por banco de dados qualquer sistema que reúna e mantenha organizada uma série de
informações relacionadas a um determinado assunto em uma determinada ordem. Outros
conceitos sobre banco de dados podem ser analisados a seguir:
Um sistema de Banco de dados não é nada mais do que um sistema de
manutenção de registros por computador. O próprio banco de dados pode
ser considerado uma espécie de sala de arquivo eletrônica – ou seja, um
depósito de um conjunto de arquivos de dados computadorizados que
oferece diversos recursos ao usuário, possibilitando-lhe a realização de várias
operações. ( DATE, 1991,p.3).
Já Korth (1989), diz simplesmente que banco de dados é uma coleção de dados
comumente usada, que contêm informações de um empreendimento em particular, ou seja, é
o arquivo físico onde estão armazenados os dados de um determinado sistema para consulta
e atualização dos dados pelo usuário.
Segundo Engles apud DATE (1991, p.9), banco de dados é :“uma coleção de dados
operacionais armazenados, usados pelos sistemas de aplicações de uma organização.” Para
ele as informações contidas em um banco de dados são chamadas de dados operacionais.
Os dados estão divididos em dados de entrada que são os dados que entram pela primeira
vez no sistema, e dados saída que são resultados do sistema.
A expressão banco de dados passou a identificar qualquer coleção de
informações na vida cotidiana, ainda que muitas vezes, sob o ponto de vista
estritamente técnico não mereceria ser assim qualificada ( JAMIL, 2001,
p.266).
Com o grande crescimento dos bancos de dados surge a necessidade de desenvolver
uma ambiente de gerenciamento de funções como manipulação, armazenamento e
recuperação da informações, dando origem aos Sistema Gerenciadores de Bancos de Dados
- SGBD.
29
Segundo Korth (1989) em um Sistema de gerenciamento de banco de dados consiste
numa coleção de dados inter-relacionados e um conjunto de programas para acessar esses
dados. “O principal objetivo de um SGBD é proporcionar um ambiente, conveniente e
eficiente, para retirar e armazenar informação no banco de dados.” O gerenciamento dos
dados envolve tanto a definição de estrutura para armazenamento como a provisão de
mecanismos para manipulá-la. Além disso, o sistema deve proporcionar a segurança das
informações armazenadas no banco de dados em situações como quedas do sistema ou
tentativas de acesso não autorizado. “E se os dados são compartilhados por diversos usuários
o sistema precisa evitar possíveis resultados anômalos”.
Figura 8. Um Sistema de Banco de Dados4
Para Date (1991) os objetivos de um SGBD são:
•
4
Isolar os usuários de detalhes mais internos do banco de dados - Abstração de dados.
www.abed.org.br/antiga/htdocs/paper_visem/ rafael_scapin/rafael_scapin01.htm
30
•
Prover independência de dados as aplicações (estrutura física de armazenamento e a
estratégias de acesso).
Algumas vantagens no uso de SGBD também apresentadas por Date (1991) são:
•
Rápidez no acesso e na manipulação à informação.
•
Redução do esforço humano (desenvolvimento e utilização).
•
Redução da redundância e na inconsistência de informações.
•
Redução de problemas de integridade.
•
Compartilhamento de dados.
•
Aplicação automática de restrições de segurança.
•
Controle de informações distribuídas fisicamente.
Já para Silberschatz (1999) algumas vantagens consideráveis são:
•
Consistência de dados, que é a padronização dos dados a serem armazenados. “O SGDB
permite que se tenha um relacionamento entre as tabelas do sistema criando com isso a
consistência nos dados armazenados”, ou seja, evitando a redundância da informação.
•
Integridade faz a manutenção da consistência dos dados, ou seja, assegura que os dados
o banco de dados estejam corretos.
•
Segurança restringe acesso a usuários que não possuem permissão para acessar certas
informações.
•
Compartilhamento de dados assegura que o efeito de qualquer transação completa seja
preservada mesmo que o sistema falhe.
31
Com a criação dos Bancos de Dados e os Sistemas Gerenciadores de Banco de
Dados, as corporações cada vez mais vêm adotando a utilização dos mesmos, e com isso à
necessidade de aprimoramento destas ferramentas como a criação dos Bancos de Dados
Orientado a Objetos, a criação de Sistemas Gerenciadores de Bancos de Dados
Distribuídos(SGBDD) e outras tecnologias como DatawareHouse e Data Mining.
Também para Korth, uma preocupação que deve ser levada em consideração é a
abstração dos dados, ou seja, o sistema deve oferecer uma visão abstrata dos dados
escondendo certos detalhes de como os dados são armazenados ou mantidos. Porém, para
que o sistema seja utilizável, os dados precisam ser recuperados eficientemente. Esta
preocupação com eficiência nos leva ao desenvolvimento de estruturas complexas para
representação dos dados no banco de dados. Com isso Korth define alguns níveis de
abstração pelos quais os banco de dados podem ser vistos.
O Nível físico: é o nível mais baixo de abstração, no qual se descreve como as dados
são armazenados. Neste nível encontramos estruturas complexas, de baixo nível, que são
descritas em detalhes.
Nível conceitual: nível onde se descreve quais dados são realmente armazenados no
banco de dados e quais os relacionamentos existentes. O nível conceitual de abstração é
mais utilizado pelos administradores de banco de dados, que devem decidir quais as
informações devem ser mantidas no banco de dados.
Nível visão: nível mais alto de abstração é o nível onde se encontra apenas partes do
banco de dados, porém podem se encontrar vários níveis dentro de um único banco de dados.
4.2
MODELO DE BANCO DE DADOS
Segundo Silberschatz (1999, p.7), modelo de dados é um conjunto de ferramentas
conceituais usadas para a descrição dos dados, relacionamentos, semântica e regras de
consistência. Já para Korth necessitamos de modelos de dados para descrever a estrutura de
um banco de dados, um modelo de dados é uma coleção de ferramentas conceituais para
descrição dos dados, relacionamentos entre os dados, semântica e restrições dos dados.
Tanto para Silberschatz (1999) como para Korth os modelos de dados estão divididos
em três diferentes grupos: modelos conceitual, modelos lógico e modelos físicos.
32
4.2.1 Modelo Conceitual
Para Korth este modelo se caracteriza por proporcionar uma ampla e flexível
capacidade de estruturação e por permitir a especificação de restrições de dados de forma
visível. Também diz que possuem vários modelos deste tipo e os mais conhecidos são:
•
Modelo entidade-relacionamento.
•
Modelo binário.
•
Modelo de semântica de dados.
•
Modelo infológico.
Neste trabalho o modelo a ser usado é o modelo entidade-relacionamento, conforme
segue.
O modelo conceitual possui alto nível de abstração e representa de forma mais natural
os fatos do mundo real e seus relacionamentos, além de ser independente do banco de dados
utilizado.
Figura 9. Modelo entidade-relacionamento
Como podemos ver na figura acima com o modelo conceitual entidade-relacionamento
pode-se definir quais são as entidades utilizadas, seus atributos e o relacionamento entre elas,
tornando assim de maior compreensão aos usuários do banco de dados.
33
4.2.2 O Modelo Entidade-Relacionamento
Como já vimos este modelo se caracteriza pela percepção do mundo real e é
composto por objetos que são as entidades e os relacionamentos que são as ligações entre
estas entidades, além de facilitar o projeto de banco de dados e permitir a especificação do
esquema.
O modelo de dados entidade-relacinamento baseia-se na percepção de um
universo constituído por um grupo básico de objetos chamados entidades e
por relacionamentos entre estes objetos. Ele foi desenvolvido a fim de facilitar
o projeto de banco de dados permitindo a especificação de um esquema de
empreendimento.Tal esquema representa a estrutura lógica global do banco
de dados.(KORTH,1989)
O modelo ER é baseado nas bases teóricas de Edgar Frank Codd de 1970 e retratam
uma visão da realidade, mostrando os relacionamentos entre os objetos. Este modelo foi
criado por Peter Chen em 1976 e foi desenvolvido para facilitar os projetos de banco de
dados, permitindo uma modelagem possível de fazer uma abstração do mundo real formando
uma visão única de todo o esquema, assim tornando possível o entendimento dos dados de
um sistema de informação. Para Silberschatz (1999, p.7), “uma regra importante é o
mapeamento das cardinalidades, as quais expressam o número de entidades as quais a outra
entidade se relaciona por meio daquele conjunto de relacionamentos”.
4.2.3 Entidades e conjuntos de entidades
Entidade é um objeto real do empreendimento relativo ao banco de dados. Por
exemplo, uma pessoa com seu CPF, é uma instância de entidade, pois esta pessoa com este
CPF é única no universo. Podendo ser concreta, uma pessoa, um computador, ou abstrata,
como um feriado, um conceito, um empréstimo ou uma consulta médica.
Então várias entidades são chamadas de conjunto de instância de entidades. Como
por exemplo, os empregados de uma empresa formam um grupo de instância de entidade que
podemos chamar de funcionário.
34
Funcionário
Depto
Figura 10. Representação de como uma entidade é especificada em um DER
4.2.4 Relacionamento e conjuntos de relacionamentos
Como já vimos anteriormente um relacionamento é uma associação entre várias
entidades. Podemos representar um relacionamento fazendo uma relação entre as duas
entidades criadas anteriormente.
Funcionário
Depto
Lotação
Figura 11. Representação de um relacionamento
Normalmente um relacionamento é identificado pela figura geométrica de um losango.
Normalmente para facilitar a visualização do esquema do banco de dados e também para
melhor entendimento dos projetistas é dado um nome ao relacionamento. No nosso caso o
nome do relacionamento entre as entidades Funcionário e Dpto é chamado de Lotação.
Um conjunto de relacionamento é um grupo de relacionamento do mesmo tipo. Que
formalmente, é uma relação matemática em que n >= 2
em um conjunto de entidades
(KORTH,1989).
4.2.5 Atributos
São dados que são associados a cada ocorrência de uma entidade ou de um
relacionamento. Uma entidade pode possuir vários atributos como, por exemplo, a nossa
entidade Funcionário pode possuir Nome, CPF, Telefone etc. Os atributos são representados
no modelo conceitual da seguinte maneira:
35
CPF
Nome
Figura 12. Representação de atributos
Para Heuser (2000) existem vários tipos de atributos que são eles:
Atributos Identificador: Cada entidade possui um identificador, este é um conjunto de
um ou mais atributos, que serve para identificar uma ocorrência da entidade das outras
ocorrências da mesma entidade.
No exemplo acima define-se o atributo CPF como
identificador, ou seja, isso significa que não haverá dois valores de CPFs iguais na entidade.
Atributos monovalorados e multivalorados: Os atributos monovalorados são os que
têm um valor específico, o atributo CPF, refere-se unicamente a um número que identifica o
funcionário.
4.2.6 Cardinalidade
Visto em Heuser (2000) cardinalidade é o número de ocorrências de uma entidade em
outra entidade através do relacionamento. Indica o número máximo de ocorrência de
entidades que pode estar associadas a uma ocorrência da outra entidade (1 ou N).
Um para um: quando um elemento da entidade A relaciona-se somente com um
elemento da entidade B. Exemplificando: um Funcionário possui uma mesa e uma mesa só
pode ser usada por um funcionário, aquela a que esta destinada.
Funcionário
Alocação
Mesa
Figura 13. Representação de cardinalidade um para um
36
Um para Muitos: Quando um elemento da entidade B relaciona-se com muitos
elementos da entidade A, mas cada elemento de A pode relacionar-se somente com um
elemento em B. Como no exemplo abaixo onde um funcionário pode estar lotado em vários
projetos, mas um projeto só pode ser gerenciado por um funcionário.
Funcionário
Gerencia
Projeto
Figura 14. Representação de cardinalidade um para muitos
Muitos para Muitos: quando muitos elementos da entidade A relacionam-se com
muitos elementos em B e vice-versa. Imagina-se agora o seguinte exemplo: um funcionário
pode fazer parte de vários projetos e os projetos tem a participação de vários funcionários.
Funcionário
Projeto
Lotação
Figura 15. Representação de cardinalidade muitos para muitos
4.2.7 Modelo Lógico
Segundo Heuser (2000) , o modelo lógico é uma espécie de visão do banco de dados
tanto para o programador como para o analista de sistema como também para o
administrador de banco de dados. Já Korth diz que o modelo lógico é usado na descrição de
dados nos níveis conceitual e visão, e estes modelos são usados para especificar a estrutura
lógica global do banco de dados e que também nos dá uma visão em alto nível de
implementação.
37
Figura 16. Modelo Lógico
4.2.8 Modelo Físico
O modelo físico é o de mais baixo nível, é onde se escolhe o tipo de estrutura de
armazenamento que será utilizada e os caminhos de acesso aos arquivos, para que as
aplicações alcancem o desempenho desejável. Neste modelo os administradores de banco de
dados devem conhecer quais são os pontos de acesso mais utilizados para criação de índices
para consultas, e também deve conhecer muito bem a arquitetura do SGBD que irá utilizar a
fim de projetar da melhor maneira o modelo físico (RAMAKRISHNAN,1997).
4.2.9 Generalização e Especialização
Generalização é um conjunto de entidades visto como uma entidade genérica que para
Korth (1989) é o resultado da união de dois ou mais conjuntos de entidades de nível mais
baixo produzindo um conjunto de entidades de nível mais alto. A generalização é possível por
que duas entidades possuem atributos em comum.
Especialização
ocorre
quando
algumas
entidades
possuem
atributos
ou
relacionamentos adicionais, sendo especializados em uma ou mais entidades. Segundo Korth
(1989) especialização é o resultado da separação de um subconjunto de entidades de nível
mais alto, formando um conjunto de entidades de nível mais baixo.
38
Figura 17. Exemplo de Generalização
4.3
O MODELO RELACIONAL
Percebemos na história de banco de dados que, o modelo relacional é relativamente
novo. Os primeiro sistemas de banco de dados se basearam no modelo hierárquico ou no
modelo em rede. Estes dois modelos mais antigos estão mais ligados a estrutura da
implementação do banco de dados do que o modelo relacional.
O modelo de dados relacional representa o banco de dados como uma
coleção de tabelas. Muito embora tabelas envolvam noções simples, e
intuitivas, há uma correspondência direta entre o conceito de uma tabela e o
conceito matemático de uma relação(KORTH,1989).
Um banco de dados relacional esquematizado cria um conjunto de relações que
permitem armazenar informações como integridade, sem redundância, tudo isso para suportar
as necessidades dos usuários na recuperação das informações armazenadas no banco. Isto é
possível quando se projeta um modelo de banco de dados onde não se armazene
informações repetidas. Neste modelo também se aplicam chave-estrangeira e chaveprimária. Um banco de dados é chamado de relacional porque o nome matemático dado para
as tabelas é “Relação”, então um banco de dados relacional é um conjunto de relações. A
relação é formada pela associação entre “Conjuntos” de dados, definidos pelos atributos de
uma entidade.
39
4.3.1 Estrutura do banco de dados
O modelo de dados relacional consiste em uma coleção de tabelas onde cada uma
destas tabelas se identificam com um nome único. O modelo relacional é claramente baseado
no conceito de matrizes, onde as chamadas linhas das matrizes seriam os registros e as
chamadas colunas das matrizes seriam os campos. As linhas de nossa relação são chamadas
de TUPLA cada coluna de nossa relação é chamada de ATRIBUTO, onde o conjunto de
possíveis valores para esses atributos são chamados de DOMÍNIO.
O esquema de uma relação, nada mais é do que os campos (colunas) existentes em
uma tabela. Já a instância da relação consiste no conjunto de valores que cada atributo
assume em um determinado instante. Portanto, os dados armazenados no Banco de Dados,
são formados pelas instâncias das relações (HEUSER, 2000, p.82).
Os valores não podem ser duplicados, não pode existir dois estados do Paraná no
conjunto de estados brasileiros, e a ordem de entrada de dados no Banco de Dados não deve
ter qualquer importância para as relações.
4.3.2 Chaves
Temos basicamente três tipos de chaves que podemos utilizar em um modelo de
banco de dados relacional e estas servem para identificar a relação entre as tuplas das
entidades, as chaves primárias, chaves alternativas e chaves estrangeiras.
Chave primária é um valor definido para uma coluna ou para um conjunto de colunas
que não se repetem dentro de uma mesma tabela. Pode se definir mais de uma coluna como
chave, então chama-se de chave primária composta.
Chave Secundária (Ternária, etc), serão chaves que possibilitarão pesquisas ou
ordenações alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da
ordenação natural (física) da tabela.
Chave Estrangeira, aquela chave que permite a ligação lógica entre uma tabela onde
ela se encontra com outra na qual ele é chave primária, além de, definir o relacionamento e
impor a integridade referencial.
40
Exemplo:
CID_CODIGO e EST_UF são chaves primárias respectivamente das tabelas Cidade e
Estado, enquanto EST_UF é chave estrangeira na tabela de cidades. É precisamente por este
campo (atributo ou coluna), que será estabelecida a relação entre as tabelas Cidade->Estado.
4.3.3 Domínios
O domínio consiste de um grupo de valores atômicos a partir dos quais um ou mais
atributos retiram seus valores reais. Por exemplo, Santa Catarina, Paraná e Rio Grande do
Sul são estados válidos para o Brasil, enquanto que Califórnia não é um estado válido pois
não pertence ao Brasil e sim aos Estados Unidos.
5
ÁLGEBRA RELACIONAL
Pode-se dizer que a álgebra relacional é um tipo de linguagem de consulta que
consiste em um conjunto de operações de entrada e produzem uma nova relação como
resultado(SILBERSCHATZ, 1999). As consultas algébricas são compostas de uma coleção de
operadores que se dividem em dois grupos:
Operações Tradicionais:
•
União
•
Intersecção
•
Diferença
•
Produto Cartesiano
Operações Especiais:
5.1
•
Seleção
•
Projeção
•
Junção
•
Divisão
SELEÇÃO
A seleção é representada pelo símbolo:
σ
e equivale a cláusula where da linguagem
SQL. Busca na tabela e retorna apenas o que atende a condição. Exemplo:
Relação = σ < predicado> (Relação).
Exemplo:
R1 = σ <emp_codigo = 1> (empresa).
42
No modelo irá retornar a empresa em que o código é igual a um.
5.2
PROJEÇÃO
Já o símbolo que representa a projeção é π. Representada pela cláusula select da
linguagem SQL. A projeção retorna todos os atributos de uma relação de acordo com a
especificação.
Notação:
π <lista de atributos> (Relação )
Exemplo:
R2 = π <emp_descricao> (empresa)
No exemplo acima será projetada a emp_descricao da relação empresa.
5.3
PROJEÇÃO E SELEÇÃO
Usam-se as duas operações juntas para que se possa projetar os atributos de acordo
com a condição estipulada. Deve-se usar uma seleção primeiro, para depois projetar os
atributos.
Exemplo:
R1 = σ <cod_emp= 1> (empresa)
R2 = π <emp_desc> (R1)
No exemplo acima retorna a descrição quando o código da empresa for igual a um.
43
5.4
OPERAÇÃO DE UNIÃO
A simbologia que representa a operação de união é
∪,e
consiste em uma união de
linhas de duas relações. Tem-se apenas a particularidade de que, as relações devem ter o
mesmo grau (mesmo número de atributos) e os atributos devem pertencer ao mesmo
domínio.
Exemplo:
R1 = π <cod_empresa> (empresa)
R2 = π <codempresa> (empresa)
R3 = R1 ∪ R2
No exemplo acima R3 irá representar a união de R1 com R2.
5.5
DIFERENÇA
Pode-se dizer que na diferença é construída uma relação, a qual terá como
resultado todas as linhas da primeira relação que não estão presentes na segunda relação e é
representada pelo sinal de subtração(-).
Segue abaixo um exemplo de uma operação de diferença, no qual R3 armazenará os
dados que estão em R1 e não estão em:
Exemplo:
R1 = π <codempresa> (empresa)
R2 = π <codempresa> (funcionario)
R3 = R1 - R2
5.6
INTERSECÇÃO
Na intersecção tem-se o retorno das linhas que estão presentes nas duas
relações. A intersecção é representada pela seguinte denotação: ∩
44
Exemplo:
R1 = π <codempresa> (empresa)
R2 = π <codempresa> (funcionario)
R3 = R1 ∩ R2
No exemplo acima R3 retornara os dados que são comuns entre R1 e R2.
5.7
JUNÇÃO
A junção é função representada pela seguinte simbologia:
a mesma constrói uma
relação a partir de duas relações específicas, nada mais é que todas as possibilidades de
pares de linhas resultantes combinadas, uma de cada relação específica, de forma que cada
par de linhas satisfaça uma condição específica. Deve-se considerar as chaves primárias e
estrangeiras ou valores iguais para a junção. Como exemplo utiliza-se duas relações empresa
e funcionário.
R1 = empresa
funcionario
R2 = π <emp_fantasia, fun_nome > (R1)
5.8
PRODUTO CARTESIANO
Para que se tenha produto cartesiano de duas relações, a relação resultante de duas
relações X e Y deve haver
constrói uma relação a partir de duas relações específicas, que
consiste na combinação de todas as linhas das duas relações. O mesmo tem representado
por X. Como exemplo, o seguinte produto cartesiano, é composto de relações, cidade e setor,
conforme segue:
5.9
DIVISÃO
A divisão é uma operação adicional que produz como resultado a projeção de todos os
elementos da primeira relação que se relacionam com todos os elementos da segunda
relação. É denotada pelo sinal aritmético da divisão (÷).
45
Exemplo:
R1 = π <nome,cód_Loc> (Empresa)
R2 = π <cód_loc=1> (Localidade)
R3 = R1 ÷ R2.
Retorna todas as empresas da seleção aplicada.
6
SISTEMA DE BANCO DE DADOS DISTRIBUÍDOS
Para Özsu e Valduriez (2001, p.1), o conceito de sistema banco de dados distribuído
(SBDD) pode ser definido como uma coleção de vários bancos de dados logicamente interrelacionados, distribuídos ao longo de uma rede de computadores. Um sistema de
gerenciamento de banco de dados distribuído(SGBDD) é definido como um sistema de
software que permite o gerenciamento do banco de dados distribuído e que torna a
distribuição transparente para o usuário.
A tecnologia de sistemas de bancos de dados distribuídos (SBDDs) é a união
daquilo que consideramos duas abordagens diametralmente opostas para
processamento de dados: as tecnologias de sistemas de banco de dados e
rede de computadores(OZSU;VALDURIEZ,2001).
Algumas características que devem ser levadas em consideração para que não se
confunda um SBDD com uma simples coleção de arquivos são: além de estarem interrelacionados deve existir uma estrutura entre os arquivos, o acesso aos dados deve ser feito
por uma interface comum e o único meio compartilhado que é usado para comunicação entre
as bases é a rede (ÖZSU; VALDURIEZ, 2001, p.5).
Em Bell e Grimsom (1992, p.44), banco de dados distribuído pode ser definido como
uma coleção integrada logicamente compartilhada de dados fisicamente distribuídos entre nós
de uma rede de computadores. “Um SGBD distribuído é o software para gerenciar um banco
de dados distribuído de maneira que os aspectos de distribuição sejam transparentes ao
usuário”.
Desde o início da utilização dos sistemas de banco de dados a idéia que prevalecia é
a que os dados operacionais de um empreendimento deveriam estar centralizados, por outro
lado, as redes de computadores promovem um modo de trabalho que se opõe a todos os
esforços de centralização, e a união destas duas linhas de pensamento nos leva ao que
chamamos hoje de sistema de banco de dados distribuído. Vale também dizer que o objetivo
mais importante de um sistema de banco de dados não é a centralização e sim a integração.
Pode-se classificar os SGBDD em dois tipos separados baseados em diferentes
filosofias:
a) SGBDD Homogêneo
47
b) SGBDD Heterogêneo.
Um SGBD distribuído homogêneo tem múltiplas coleções de dados e integra múltiplos
dados e recursos. Este se assemelha a um banco de dados centralizado, mas ao invés disso,
o dado é distribuído através de um número de sites de uma rede.
Características:
•
Todos os sites têm software idêntico;
•
Estão conscientes uns dos outros e cooperam no processamento dos pedidos dos
utilizadores;
•
Cada site aceita perder parte da sua autonomia em termos de direitos de mudança de
esquema e software;
•
O usuário tem a impressão de um sistema único.
Figura 18. Arquitetura de um SGBDD homogêneo (DISTRIBUTED DATABASE SYSTEMS,
p.46)
48
Já os SGBDD heterogêneos são caracterizados pelo uso de diferentes bancos de
dados, diferentes sistemas
incluindo hardware e software diferentes em sites diferentes,
diferentes sistemas operacionais e diferentes protocolos.
Características:
•
Sites diferentes podem usar esquemas e software diferentes, diferenças nos esquemas
constituem problemas complicados no processamento de consultas e diferenças no
software constituem problemas complicados no processamento de transações;
•
Os
sites podem não estar conscientes uns dos outros e poderão fornecer apenas
capacidades limitadas para cooperação no processamento de transações.
Na figura abaixo podemos ver graficamente um exemplo de modelo que ilustra o
propósito deste trabalho onde o site 1 é a matriz de uma transportadora e os sites 2, 3, 4 são
as filias que terão acesso aos dados da matriz e vice-versa. Cada site terá sua própria base
de dados e a união de todos os sites formam um único banco de dados onde o SGDB através
de seus recursos mantém a integridade de cada banco de dados local e do banco de dados
geral.
Site 1
Site 4
Rede de
Site 2
Comunicação
Site 3
Figura 19. Exemplo de um Sistema de Banco de Dados Distribuídos(OZSU; VALDURIEZ,
2001, p.8)
49
6.1
CARACTERÍSTICAS DE SBDDS
6.1.1 Gerenciamento transparente de dados Distribuídos
A principal característica de um sistema transparente é a capacidade de não mostrar
os detalhes de implementação para o usuário, e o suporte para desenvolvimento de vários
tipos de aplicativos. Em, Özsu e Valduriez (2001,p 9) todos os SGBDs podem ser totalmente
transparentes tanto os distribuídos como os centralizados, mas, para que a transparência
ocorra, o sistema deve gerenciar várias características para oferecer transparências, as quais
são descritas abaixo.
6.1.1.1 Independência de dados
Consiste na capacidade de tornar as características físicas dos dados (como
localização, estrutura, tamanho, etc) transparentes para a aplicação. Com isto, os programas
aplicativos passam a ter apenas uma visão lógica da base de dados, que não é influenciada
por eventuais modificações na forma de armazenamento dos dados. Significa também que
devem existir duas sub-linguagens incorporadas ao banco de dados: uma Linguagem de
Definição de Dados (LDD) e uma Linguagem de Manipulação de Dados (LMD).
A independência de dados consiste em uma forma fundamental de transparência é
também o único tipo importante dentro do contexto de um SGBD centralizado. Ela se refere à
imunidade de aplicativos do usuário a mudanças na definição e na organização de dados, e
vice-versa. A definição dos dados pode ocorrer em dois níveis, o primeiro é conhecido como
definição do esquema
onde a estrutura lógica é especificada e o outro é chamado de
descrição dos dados físicos e é onde a estrutura física dos dados é definida (OZSU;
VALDURIEZ, 2001, p.10).
6.1.1.2 Transparência de rede
O comportamento dos programas aplicativos deve ser o mesmo independentemente
da distribuição na rede, ou seja, em um ambiente de gerenciamento de banco de dados
distribuído existe
mais um recurso compartilhado que para o usuário deve parecer
50
transparente. Esse requisito possui como base a criação de um Espaço Computacional
Compartilhado Distribuído (ECCD), que cria a ilusão de um único espaço de endereçamento
para todas as entidades do sistema. Assim não haveria nenhuma diferença entre aplicativos
de banco de dados que fossem executados em um banco de dados centralizado e aqueles
executados em um banco de dados distribuído.
A transparência de rede pode ser dividida em dois pontos de vista, dos serviços
fornecidos e dos dados. Na primeira perspectiva é desejável que os serviços sejam acessados
por meios uniformes. Já na perspectiva de SGBD a transparência de rede exige que o usuário
não tenha que especificar onde os dados estão localizados.
6.1.1.3 Transparência de replicação
Pode-se dizer que replicação é a copia de informações de um ou mais banco de dados
para outro semelhante. É desejável distribuir os dados de forma replicada pelas máquinas de
uma rede por razões de desempenho, confiabilidade e disponibilidade. A transparência de
replicação refere-se apenas a existência de réplicas pela rede, e não a sua posição real. Se
existem réplicas de objetos (relações/tabelas, tuplas/registros, atributos/colunas) do banco de
dados, sua existência deve ser controlada pelo sistema e não pelo usuário. A criação de
réplicas auxilia nos fatores de desempenho, confiabilidade e disponibilidade, pois requisitos de
um usuário distinto e comumente acessado podem ser acomodados com maior facilidade.
Além disso, como existe mais de uma cópia dos dados, se uma máquina falhar os dados irão
continuar disponíveis na rede de tal forma que o usuário não perceba onde está acessando
estas informações.
6.1.1.4 Transparência de fragmentação
Consiste em dividir as relações/tabelas em fragmentos menores e tratar cada
fragmento como uma relação de um banco de dados separado. Se as relações/tabelas do
banco de dados são fragmentadas, então o sistema tem que lidar com a conversão de
consultas do usuário definidas em relações globais para consultas definidas em fragmentos.
51
Existem dois tipos gerais de fragmentação, fragmentação horizontal e fragmentação
vertical. As formas de fragmentação serão apresentadas e aprofundadas mais à frente.
6.1.2 Confiabilidade em transações distribuídas
Pode-se dizer que os SGBDs distribuídos nos proporcionam uma maior confiabilidade
por possuírem componentes compartilhados que eliminam pontos únicos de falha. Isso
significa que se houver falha em um único site ou em um “link” de comunicação apenas o
ponto que falhou vai ficar inativo e não todo o sistema, assim o usuário continua tendo acesso
a uma parte dos dados. No caso de banco de dados distribuído, as transações distribuídas e
os protocolos de aplicativos têm a responsabilidade de controlar as permissões de acesso das
partes disponíveis do banco de dados.
Uma transação é uma unidade básica de computação consistente e confiável,
formada por uma seqüência de operações de banco de dados executadas
como uma ação atômica. Ela transforma um estado consistente do banco de
dados em outro estado consistente de banco de dados, mesmo várias dessas
transações são executadas de forma concorrente, e até mesmo quando
ocorrem falhas(OZSU; VALDURIEZ,2001,p.16).
Pode-se dizer também que os SGBD distribuídos não impõe a atomicidade de
transações distribuídas, mas fornece as primitivas básicas pelas quais os aplicativos do
usuário podem impor essa atomicidade. Estas primitivas são conhecidas como propriedades
ACID que indicam a preservação da integridade dos dados do banco, e são:
1. Atomicidade: ou todas as operações da transação são apropriadamente refletidas no
banco de dados ou nenhuma é.
2. Consistência: A execução de uma transação preserva a consistência do banco de dados.
3. Isolamento: embora múltiplas transações possam ser executadas concorrentemente, cada
transação deve desconhecer as outras transações concorrentes em execução. E
resultados intermediários de transações devem ser escondidos de outras transações
concorrentes.
52
4. Durabilidade: após uma transação ser completada com sucesso, as mudanças que ela fez
no banco de dados persiste, mesmo se houver falha no sistema.
6.1.3 Desempenho otimizado
Em geral o desempenho otimizado de um SGBD distribuído se baseia em dois pontos:
1. SGBD distribuído é fragmentado permitindo que os dados fiquem armazenados próximos
a seus pontos de acesso proporcionando duas vantagens consideráveis:
•
As transações agem sobre parte do banco de dados fazendo com que a
concorrência pela CPU e pelos periféricos de entrada e saída (E/S) sejam menos
executadas do que nos bancos de dados centralizados;
•
E a localização reduz os atrasos de acesso remoto e conseqüentemente o tempo
de recuperação dos dados.
2. paralelismo entre consultas é o outro ponto do desempenho onde um SGBD distribuído
torna possível a execução de mais de uma consulta ao mesmo tempo, ou desmembrar
essa consulta em várias subconsultas denominadas de intraconsultas.
6.1.4 Expansão de sistemas mais fácil
Para Özsu e Valduriez (2001, p.20), é mais fácil acomodar tamanhos crescentes de
banco de dados em um ambiente distribuído, pois raramente são necessárias revisões
importantes do sistema, a expansão pode ser manipulada aumentando a capacidade da rede.
Um outro aspecto que pode ser levado em consideração é o aspecto econômico, pois custa
muito menos formar um sistema usando computadores menores com capacidade equivalente
a uma máquina de grande porte.
53
6.2
PROBLEMAS E DIFICULDADES DA DISTRIBUIÇÃO DE BANCO DE DADOS
Os problemas encontrados em um sistema de banco de dados impõem uma
complexidade adicional em um ambiente distribuído, essa dificuldade adicional ocasiona
novos problemas influenciados principalmente em três fatores:
Ambiente distribuído: os dados podem ser replicados em um ambiente distribuído,
um banco de dados pode ser projetado de tal forma que o banco de dados inteiro, ou parte
dele, resida em locais diferentes. O banco de dados distribuído é responsável por escolher
uma das cópias dos dados solicitados para acesso em cada recuperação, assegurar que o
efeito de uma atualização se reflita em toda e qualquer cópia desse item de dados .
Falhas em sites isolados: em caso de falha ou se um site estiver fora do ar durante a
execução de uma atualização o sistema deverá assegurar que os efeitos se reflitam nos
dados residentes nos sites defeituosos assim que os mesmos se recuperarem.
Disponibilidade: como cada site não pode ter informações instantâneas sobre ações
que estão sendo realizadas no momento nos outros sites, a sincronização de transações em
vários sites é consideravelmente mais difícil que no caso de um sistema centralizado.
Além desses fatores de complicação outros fatores em potencial são discutidos em
seguida.
Complexidade : em fator da distribuição a complexidade de um sistema de
gerenciamento de banco de dados aumenta em relação a um sistema centralizado, pois além
de encontrar problemas idênticos aos encontrados em um sistema centralizado, encontra-se
um conjunto de problemas não resolvidos providos da distribuição.
Custo: os sistemas distribuídos além de exigirem hardware adicional por residirem em
locais diferentes, exigem alguns de itens software e de comunicação adicionais e mais
complexos para resolver alguns problemas técnicos. O fator de custo mais importante é o da
replicação do esforço. Como as instalações de computadores são configuradas em diferentes
locais, torna-se necessário empregar pessoas para manter estas instalações. Por isso o
compromisso entre o aumento da rentabilidade devido ao uso mais eficiente e oportuno das
informações e o aumento dos custos de pessoal tem de ser analisado com cuidado.
54
Distribuição de controle: pode ser visto tanto como uma vantagem como uma
desvantagem, pois, a distribuição cria problemas de sincronização e coordenação tornando o
controle distribuído uma obrigação.
Segurança: ao contrário dos bancos de dados centralizados que possuem uma certa
facilidade no aspecto segurança por estar em um único lugar, em um sistema de banco de
dados distribuído
além dos problemas encontrados em bancos de dados centralizados,
encontra-se uma rede envolvida, e esta possui seus próprios requisitos de segurança que se
agregam ao do banco de dados, tornando assim a segurança em um sistema de banco de
dados distribuído mais complexa do que em sistemas centralizados.
6.3
RECUPERAÇÃO
Para Bell e Grimson (2002, p.224) a habilidade de assegurar a consistência de um
banco de dados na presença de falhas imprevisíveis de componentes de hardware e de
software é uma característica essencial de todos os sistemas de gerenciamento de banco de
dados. O papel de gerenciamento de um banco de dados deve garantir a recuperação do
banco de dados em uma forma consistente.
6.3.1 Controle de Transações e Recuperação
A transação representa a unidade básica da recuperação em um sistema de
gerenciamento de banco de dados. O papel do gerente da recuperação é garantir duas das
quatro propriedades de A.C.I.D, a durabilidade e atomicidade na presença de falhas
imprevisíveis. A consistência e o isolamento, outras duas propriedades de A.C.I.D, são
principalmente de responsabilidade do módulo de controle da concorrência (BELL; GRIMSON,
1992, p.226).
O gerente de recuperação tem que se assegurar de que, na recuperação de falhas,
qualquer uns todos os efeitos de uma transação dada, que esteja gravado permanentemente
no Banco de Dados(BD). A situação é complicada pelo fato que a gravação no BD não é um
procedimento atômico (única etapa), e consequentemente é possível que uma transação
tenha cometido apenas uma etapa e não terem sido gravado permanentemente no BD por
55
não ter alcançado o mesmo. Quando uma transação emite uma gravação ao BD, os dados
estão transferidos do espaço de trabalho local para a uma área (buffer) da memória do BD.
Esta área ocupada é uma área especial na memória principal onde os dados são transferidos
para um armazenamento secundário. Está área de buffer opera como um esconderijo
temporário em que as parcelas do BD podem residir temporariamente. E somente quando
todos os índices do buffer
foram nivelados é que as operações de update podem ser
executadas ao armazenamento secundário e consideradas como permanentes.
As falhas podem variar desde falhas simples, que afetam somente uma transação a
uma falha maior que afeta todas as transações em um determinado local. Os meios de
armazenamento podem falhar em consequência dos ruídos elétricos, discos e pelas
conseqüências do ambiente distribuído estar em uma rede que pode falhar ao
fazer a
comunicação entre sites. A principal função do gerenciamento de recuperação é de identificar
quais as transações foram executadas com sucesso e quais as que tiveram problemas. Os
arquivos (logs) do banco de dados tem um papel essencial nesta recuperação.
6.3.2 Arquivos de Log
Todas as operações no BD realizadas por todas as transações são gravadas em um
arquivo de log. Tem-se um arquivo de log para cada SGBD que é compartilhado por todas as
transações sob o controle daquele SGBD, em um ambiente de banco de dados
distribuído(BDD), cada local terá seu próprio registro separado. Estes arquivos são gerados
pelos SGBDS cada vez que um dos seguintes comandos é emitido por uma transação:
•
inicia transação;
•
escrita ( inclusão, exclusão e atualização);
•
confirma transação;
•
aborta transação.
Os registros de logs são vitais para o processo de recuperação, para tanto,
normalmente é duplicado de modo que, por acaso uma cópia for perdida ou danificada, uma
56
segunda possa ser usada. Essa cópia normalmente era feita em fitas magnéticas por serem
mais confiáveis e mais baratas. Entretanto, os SGBD’s de hoje podem recuperar-se
rapidamente das falhas por possuírem um sistema de armazenamento próprio, de acesso
rápido e mais confiável.
6.3.3 Ponto de checagem
Uma as principais dificuldades do gerenciamento de recuperação é descobrir qual a
principal falha e quais foram às transações que foram executas e quais não foram.
TC5
TC4
TC3
TC2
TC1
Assíncrono
(a)
tc
Falha
tf
TC5
TC4
TC1
(b)
Síncrono
tc
Falha
tf
Figura 20(a). Classificação para transação usando pontos de checagem assíncrono
Figura 20(b). Classificação para transação usando pontos de checagem síncrono.
Para limitar a busca, são criados pontos de verificação periódicos que é onde o
gerente de recuperação pode voltar a um ponto mínimo. Existem acessos para pontos de
checagem, nomeados síncronos e assíncronos. Com ponto de checagem assíncrono é
57
possível continuar o processo do sistema a partir de um ponto criado como mostra na figura
acima. Já com um checkpoint síncrono , o sistema pára, aceitando qualquer nova transação
até que todas as transações executadas tenham acabado.
6.4
CAUSAS DE FALHAS
Existem muitas causas diferentes para falhas, mas pode-se classificar como principais
causas de falhas em SGBDD as seguintes:
•
falha de transação local;
•
falhas em sites;
•
falhas midias;
•
falhas na rede de comunicação.
6.4.1 Falha do local da transação
As falhas de uma transação individual pode ser causadas em várias maneiras:
1) Aborto induzido da transação: neste caso o programador da aplicação escreveu o
código para prever um erro em particular, o gerenciamento recuperação executa
conseqüentemente rollback da transação e nenhuma outra transação é afetada.
2) Falha imprevista da transação : estes tipos de falhas são causadas por erros em
programas de aplicações. Neste caso o sistema deve detectar que a transação falhou e
informar ao gerente de recuperação que deve fazer rollback da transação. Nenhuma outra
transação deve ser afetada.
3) Aborto induzido pelo sistema: ocorre quando uma transação que está sendo executada
se opõe a uma outra transação, neste caso o sistema deve prover além de rollback da
transação um bloqueio das demais transações que estão sendo executadas.
58
As falhas de transação são diretamente voltadas ao software, por isso, as estatísticas
a respeito das falhas em transações são escassas e mesmo que houvessem poderiam ser
consideradas duvidosas, pois retratariam a análise de um sistema ou caso em especial.
6.4.2 Falhas em sites
Estes tipos de falhas geralmente estão relacionadas à falhas de hardware. Desta
forma a análise e caracterização da falha tornam-se difícil. Considerando que a falha está
geralmente associada à perda de informação, uma solução considerada simples é a utilização
de banco de dados secundários podendo ser até mesmo em um outro site.
6.4.3 Falhas de mídia
As falhas de mídia geralmente são representas como erro de sistema operacional,
uma solução rápida e simples para o problema é a utilização de algum sistema de
espelhamento ou replicação local do sistema de armazenamento (discos
ou fitas
magnéticas).
6.4.4 Falhas na rede de comunicação
As falhas apresentadas acima são tanto de caráter centralizado como distribuído,
porém, as falhas de comunicação são unicamente de caráter distribuído. Uma característica
interessante é o particionamento da rede, ou seja, quando a linha cai forma-se duas sub-redes
isoladas, o que pode não acarretar grandes prejuízos, principalmente caso as técnicas de
replicação tenham sido utilizadas. Em caso de uma mensagem não alcançar seu destino, dois
procedimentos podem ocorrer, a mensagem pode ser bufferizada para posterior envio assim
que o site remontar sua conexão, ou simplesmente ser perdida.
A utilização de sistemas de temporização são imprescindíveis neste contexto, bem
como deve-se prover um mecanismo de informação ao remetente da mensagem, segundo
Bell e Grimson.
59
6.5
PROTOCOLOS DE EFETIVAÇÃO
Pode-se dizer que para garantir atomicidade entre os sites, quando uma transação T é
iniciada e envolve mais de um site, todos os sites envolvidos com a transação T devem
concordar com o término da mesma. É preciso que T seja efetivada em todos os sites, ou
então, deverá ser abortada em todos eles. Para assegurar que isso ocorra, o coordenador da
transação T precisa executar um protocolo de efetivação.
Para Silberschatz, Korth e Sudarshan(1999) os protocolos de efetivação mais simples
e mais utilizados são os protocolos de efetivação em duas fases(two-phase commit protocol –
2PC) e o protocolo de efetivação em três fases (three-phase commit protocol- 3PC) que um
pouco mais complexo mas elimina algumas desvantagens do protocolo de efetivação em duas
fases.
6.5.1 Protocolo de efetivação em duas fases (2PC)
Em Silberschatz, Korth e Sudarshan (1999, p. 606) efetivação em duas fases pode ser
exemplificada por: “ Seja T uma transação iniciada no site S1 e seja C1 o coordenador da
transação S1”.
Quando a transação T termina, isto é, quando todos os sites em que T é executada
informam a C1 que a transação esta completa é que se inicia o protocolo 2PC, ou seja, um
único coordenador global é que decide se a transação vai ser validada ou se vai ser abortada,
e os demais participantes que executam os acessos e os recursos da transação, apenas
votam se a transação vai ser validada ou abortada. Se um participante votar para abortar a
transação, o coordenador tem que aceitar sua decisão e aborta a transação, se todos os
participantes votarem para que se efetive a transação então o coordenador deve efetivá-la
para todos.
A idéia central do protocolo de efetivação em duas fases denota a conversa entre um
site coordenador e os demais sites. A troca de mensagens retrata considerações a respeito de
bloqueio de recursos e da possibilidade de execução da transação corrente. O protocolo 2PC
pode ocorrer de forma centralizada (em um único site) ou de forma distribuída (a partir de um
60
site especifico),
tendo os mesmos passos e a mesma metodologia iguais para as duas
situações.
6.5.1.1 Variações no modelo 2PC
Segundo Bell e Grimson(1992) o protocolo de efetivação em duas fases é eficiente do
ponto de vista da transação, porém pode-se realizar algumas variações no modelo a fim de
aumentar sua performance, principalmente se considerada a característica dinâmica do
processo como um todo.
Protocolo 2PC com Abort Presumido: Esta técnica presume-se em otimizar o
protocolo utilizando-se de informações a respeito de estados anteriores dos sites. Com isso é
possível que se tenha um histórico de disponibilidades dos sites, encontrando assim
informações indisponíveis. A vantagem na utilização desta metodologia é que antes mesmo
do inicio da troca de mensagens o sistema irá presumir um abort, melhorando a perfomance.
Protocolo 2PC com Commit Presumido: Este protocolo baseia-se na idéia de que se
nenhuma informação sobre uma transação existir, esta poderá ser considerada executada. A
utilização deste protocolo visa eliminar o problema que pode ocorrer com o protocolo com
abort presumido, que diz respeito à possibilidade do coordenador considerar erroneamente o
abort presumido.
6.5.2 Protocolo de efetivação em três fases (3PC)
O protocolo de efetivação em três fases designa um protocolo de não utilização de
bloqueio. A idéia baseia-se em não bloquear um certo recurso quando este fizer parte de um
site que esteja em um estado de falha. Porém deve-se criar um ambiente onde se garanta a
atomicidade das transações, tal como o 2PC.
Pode-se dizer que a grande diferença do protocolo 2PC para o 3PC é que o no 3PC
existe uma fase de controle a mais no protocolo, assim, tem-se a possibilidade de gerar o
bloqueio dos recursos em uma fase mais adiante do processo, e o que diminuirá o número de
conflitos a recursos, e aumentará a performance geral do sistema. As mesmas considerações
deverão ser feitas quanto ao protocolo de 2 fases, com a significativa diferença de que há um
61
estado de pre-commit. Assim, antes de se enviar um comando de commit e finalizar a
operação o coordenador enviará um pre-commit, que é o momento quando a transação será
preparada. Nota-se que com esta técnica pode reduzir o tamanho do átomo da transação,
reduzindo consideravelmente o risco de conflitos e a necessidade de reinicializações.
Novamente, todas as considerações quanto a timeouts para os participantes deverão
ser feitas, considerando agora o novo estado agregado de pre-commit.
Da mesma forma devem ser feitas considerações quanto à falhas que venham a
ocorrem durante o estado de pre-commit, exatamente da mesma forma que foi mencionado
no protocolo 2PC. Sendo este o último momento em que o procedimento poderá ser
recuperado, do ponto de vista de sua recuperação.
Concluindo a análise do 3PC perante o 2PC evidencia-se a vantagem do não bloqueio
(durante o processo) dos dados pelo 3PC, porém atesta-se no mesmo instante a sua
vulnerabilidade, que culmina em um ganho da performance total, devido a redução do número
de bloqueios, que gerarão menos conflitos culminando em menos reinicializações.
7
ARQUITETURA DE SGBDS DISTRIBUÍDOS
A arquitetura de um sistema define sua estrutura, ou seja, identificam-se os
componentes a serem utilizados, atribui-se funções aos componentes e especificam-se os
inter-relacionamentos e interações entre esses componentes.
Segundo Ozsu e Valduriez(2001) para projetar um modelo arquitetônico de um
SGDBDS distribuído deve-se levar em consideração três características: a autonomia de
sistemas locais, sua distribuição e sua heterogeneidade.
7.1
AUTONOMIA
Para Özsu e Valduriez (2001, p.88), “a autonomia se refere à distribuição de controle,
não de dados. Ela indica até que grau SGBDs individuais podem operar independentemente”.
Alguns fatores da autonomia são explícitos, como, o fato dos sistemas componentes trocarem
ou não informações, de executar transações independentemente e de um deles ter ou não
permissão para modificá-las.
Segundo Gligor e Popescu-Zeletin apud Özsu (2001), especificam as dimensões de
autonomia como:
1. As operações locais dos SGBDs individuais não são afetadas por sua participação no
sistemas de vários bancos de dados;
2. A maneira pela qual os SGBDs individuais processam suas consultas não deve afetar o
conjunto;
3. A consistência do sistema também não pode ser afetada quando ocorre a junção dos
bancos ou um deles desliga-se do conjunto.
Já segundo Du e Elmagarmid apud Özsu (2001), especifica as dimensões de
autonomia como:
1. Autonomia de projeto: SGBDs individuais são livres para usar o modelo de dados e as
técnicas de gerenciamentos que preferirem.
63
2. Autonomia de comunicação: cada SGBD é livre para tomar sua própria decisão quanto ao
tipo de informação que deseja fornecer ou ao software que controla sua execução.
3. Autonomia de execução: cada SGBD executa as transações do modo que desejar.
Uma última característica importante é o isolamento total, onde os sistemas individuais
são SGDBs independentes, não sabendo da existência de outros SGBD e sem capacidade de
comunicação.
7.2
DISTRIBUIÇÃO
Pode-se dizer que autonomia trata de questões sobre distribuição de controle, e a
distribuição refere-se aos dados, ou seja, a distribuição física dos dados. Em
Özsu e
Valduriez (2001, p.89) diz que existem várias maneiras de se distribuir SGBDs, mas pode-se
dividir as alternativas de distribuição em duas classes: a distribuição cliente/servidor e a
distribuição não hierárquica.
7.3
HETEROGENEIDADE
Observa-se com a utilização de SGBDs distribuídos vários níveis de heterogeneidade,
por exemplo, diferenças em hardware, software, protocolos de interligação de rede e até
mesmo variações em gerenciadores de dados. Para este trabalho pode-se dizer que as
diferenças mais importantes esta relacionada a : modelos de dados, linguagens de consulta e
protocolos de gerenciamento de transação.
Muitos estudos são feitos para padronização dos SGBDS distribuídos, mas neste
trabalho veremos duas arquiteturas de referência para um SGBD distribuído: sistemas clienteservidor, SGBDs distribuído não hierárquicos.
64
7.4
SISTEMA CLIENTE-SERVIDOR
Uma arquitetura criada na década de 1990, caracterizada por fornecer uma arquitetura
em dois níveis, dividindo as funções um duas classes, funções de servidor e funções de
cliente, tornando-se assim mais fácil de gerenciar a complexidade dos SGBDs modernos e a
complexidade da distribuição (LONEY, 1999, p.504). No entanto, é importante observar que,
computação cliente/servidor é diferente de SGBD cliente/servidor, pois uma trata apenas dos
processos e a outra refere-se a máquinas reais em locais diferentes.
Figura 21. Arquitetura cliente/servidor
Pode-se dizer que a maior parte do gerenciamento dos dados é feita pelo servidor, ou
seja, todo o processamento de otimização de consultas, gerenciamento de transações e
gerenciamento de armazenamento são administrados pelo servidor. No cliente fica apenas à
parte de interface com o usuário e alguns processos que podem ser tratados em cachê como,
por exemplo, o gerenciamento dos bloqueios de transações. Este tipo de arquitetura é
bastante comum em sistemas relacionais, nos quais a comunicação entre o cliente e o
servidor é feita através de instruções SQL. Sendo assim o servidor faz todo o trabalho e
devolve ao cliente apenas a relação resultante.
Segundo Ozsu; Valduriez(2001) existe vários tipos de arquitetura cliente/servidor,
porém o mais simples e mais utilizado é o caso em que existe um único servidor e vários
clientes, esta arquitetura é chamada de vários clientes-servidor único.
Deve-se salientar que a arquitetura de um sistema de banco de dados distribuídos é a
de servidor/servidor, no qual os servidores compartilham os dados entre si. Quando um dos
65
servidores requer uma transação junto ao outro, o servidor remetente age como cliente, e o
outro executa as instruções que lhe são passadas, retornando os resultados obtidos.
Figura 22. Arquitetura servidor/servidor
7.5
SISTEMAS DISTRIBUÍDOS NÃO HIERÁRQUICOS
A grande diferença dos sistemas não hierárquicos é que não existe distinção entre
máquinas clientes e servidoras, ou seja, cada máquina tem a funcionalidade de SGBD e pode
comunicar-se com outras máquinas para executar transações nos bancos. Outras
características importantes a serem mencionadas são: os esquemas conceituais locais são
mapeamentos do esquema global em cada site, os banco de dados são projetados top-down,
ou seja, de cima para baixo e também tem-se a presença de um administrador de banco de
dados em cada site. Esse tipo de sistema pode ser definido como “sistemas completamente
distribuídos”.
Segundo Ozsu; Valduriez(2001) em um sistema não hierárquico as máquinas são
compostas de processador do usuário e o processador de dados. Essa divisão ocorre para
que haja um controle local sobre a administração dos dados. O processador do usuário possui
quatro elementos :
66
1. O tratador da interface do usuário: responsável pela interpretação dos comandos do
usuário e pela formatação dos dados do resultado conforme retornam.
2. O controlador de dados semânticos: utiliza as restrições de integridade e as
autorizações definidas como parte do esquema conceitual global, afim de verificar se a
consulta do usuário pode ser processada.
3. O otimizador e decompositor de consultas globais: é responsável por definir a
estratégia para executar consultas globais e transformá-las em consultas locais.
4. O monitor de execução distribuída: faz a coordenação da execução distribuída da
solicitação do usurário.
O processador de dados é composto por três elementos:
1. O otimizador de consulta local: atua como seletor de caminho de acesso, ou seja, é
responsável pela escolha do melhor caminho de acesso para acessar qualquer dado.
2. O gerenciador de recuperação local: garante que o banco de dados local permanecerá
consistente, mesmo na situação de falhas.
3. O processador de suporte runtime: além de conter o gerenciador de buffers do banco
de dados, que é responsável por manter os buffers de memória principal e gerenciar os
acessos aos dados, faz o acesso fisicamente ao banco de dados de acordo com a
estratégia gerada pelo otimizador de consultas.
7.6
PROJETO DE BANCO DE DADOS DISTRIBUÍDO
Pode-se dizer que até este momento vimos vantagens, problemas, alternativas e
possibilidades de distribuição de banco de dados, mas em um projeto de banco de dados
distribuído é que percebemos realmente a complexidade da distribuição. Em um projeto de
sistemas de computadores distribuído tomam-se decisões sobre a distribuição dos dados, dos
programas pelos sites e até mesmo da própria rede.
Segundo Levin e Morgan apud Ozsu (2001) a organização de sistemas distribuídos
pode ser pesquisada através de três dimensões ortogonais:
67
•
Nível de compartilhamento: pode-se ter: nenhum compartilhamento; onde cada site
possui seus dados e os mesmos não possuem acesso a qualquer arquivo de outros sites.
Também temos o nível de compartilhamento de dados; onde todos os programas são
replicados em todos os sites. E por último o compartilhamento de dados mais programas;
neste caso tanto os programas como os dados podem ser compartilhados.
•
Comportamento dos padrões de acesso: os padrões de acesso podem ser estáticos ou
dinâmicos, ou seja, podem se alterar no decorrer do tempo ou não.
•
Nível de conhecimento sobre o comportamento do padrão de acesso: essa é uma
alternativa de dimensão teórica. As alternativas práticas são as que os projetistas tenham
informações completas ou parciais do padrão de acesso dos usuários.
Para Ceri et al. apud
Ozsu e Valduriez (2001) um projeto de banco de dados
distribuído pode ser resolvido de duas maneiras: abordagem top-down e a abordagem bottomup.
O processo de top-down caracteriza-se pelas atividades começarem com a análise dos
requisitos e em seguida duas atividades paralelas: projeto de visão e projeto conceitual. O
projeto de visão é responsável pela definição das interfaces para os usuários e o projeto
conceitual é responsável por determinar os tipos de entidades e seus relacionamentos.
Também no projeto top-down, devemos se preocupar em manter um relacionamento
entre o projeto conceitual e o projeto de visões para garantir que os requisitos de entidades e
relacionamentos façam parte do esquema conceitual para todas as visões.
68
Análise de
requisitos
Requisitos do
sistema
Entrada
Projeto
conceitual
Integração de visões
Informações
Esquema
Projeto de
visões
Definições do
esquema
Entrada
Projeto
e
distribuição
Do usuário
Esquemas
conceituais locais
Projeto
físico
Esquema
físico
Feedback
Observação e
monitoramento
Feedback
Figura 23. Processo do projeto top-down (ÖZSU; VALDURIEZ,2001)
Na abordagem bottom-up o principal objetivo é de integrar esquemas conceituais
locais em um único esquema global. Esta abordagem é apropriada para projetos de banco de
dados que esta sendo iniciado e está sendo projetado desde o início.
O processo de bottom-up existe principalmente em um contexto em que os bancos de
dados são heterogêneos.
Porém, este trabalho concentra-se nas principais questões do
projeto top-down: fragmentação e alocação.
Para Özsu; Valduriez (2001), existem duas formas fundamentais de fragmentação
horizontal e vertical, pode-se unir as duas estratégias formando a fragmentação híbrida. Uma
das principais razões para fragmentar as relações é que diminuirá o tráfego na rede cada vez
que o usuário fizer uma solicitação ao sistema ou efetuar uma transação, isso sem que haja
também uma degradação de performance.
69
7.7
FRAGMENTAÇÃO HORIZONTAL
Segundo Özsu; Valduries(2001) a fragmentação horizontal consiste em particionar
uma relação por suas tuplas fazendo com que cada fragmento tenha um subconjunto de
tuplas da relação que obedeça a um critério especifico. Pode-se dividir este tido de
fragmentação em: primária e derivada, sendo que a diferença entre a fragmentação horizontal
primária e a fragmentação horizontal derivada é que na primeira a fragmentação é executada
a partir do uso de predicados sobre a relação que se deseja particionar e, na segunda, a
relação resultado da definição de predicados sobre outra relação que não aquela que vai ser
fragmentada.
Empresa 1
EMP_COD EMP_NOME
EMP_CNPJ
EMP_TEL
LOC_COD
1
Expresso S. M
87.542.254/0001-20 323-1050
1
2
UnoChapeco
05.253.215/0001-55 323-2015
1
3
Coca-Cola
00.000.252/2253-22 362-2536
3
4
AMBEV
32.542.366/0001-23 586-3233
3
Figura 24. Base de Dados de exemplo de fragmentação horizontal
No caso da fragmentação horizontal primária é definida conforme o exemplo abaixo da
seguinte maneira:
R1 = σF(empresa), sendo que
F
representa a fórmula empregada para obter o
fragmento R1.
Pode-se também representar da seguinte maneira os fragmentos 1 e 2 do exemplo
abaixo:
70
EMPRESA1 = σ <loc_cód=1 > (EMPRESA)
EMPRESA2 = σ < loc_cod = 3 > (EMPRESA)
A partir da relação acima pode-se dividir em fragmentos baseados em suas tuplas:
EMPRESA1
EMP_COD EMP_NOME
EMP_CNPJ
EMP_TEL
LOC_COD
1
Expresso S. M
87.542.254/0001-20 323-1050
1
2
UnoChapeco
05.253.215/0001-55 323-2015
1
EMPRESA2
EMP_COD EMP_NOME
EMP_CNPJ
EMP_TEL
LOC_COD
3
Coca-Cola
00.000.252/2253-22 362-2536
3
4
AMBEV
32.542.366/0001-23 586-3233
3
Figura 25. Exemplo Fragmentação horizontal
A relação foi dividida em duas, mas a título de exemplificação uma única relação pode
ser particionada em quantos fragmentos forem necessários.
Na fragmentação horizontal derivada é necessário fazer uma semijunção para que
possa ocorrer o particionamento.
71
LOCALIDADE
LOC_COD LOC_DESC
1
Chapecó
2
Pinhalzinho
3
Nonoai
EMPRESA
EMP_COD EMP_NOME
EMP_CNPJ
EMP_TEL
LOC_COD
1
Expresso S. M
87.542.254/0001-20 323-1050
1
2
UnoChapeco
05.253.215/0001-55 323-2015
1
3
Coca-Cola
00.000.252/2253-22 362-2536
3
4
AMBEV
32.542.366/0001-23 586-3233
3
Figura 26. Base de Dados de exemplo de fragmentação horizontal
Fragmento1 = localidade
Desc = ‘Chapeco’
LOC_DESC
empresa
EMP_COD
EMP_NOME
Chapecó
1
Expresso S. M
Chapecó
2
UnoChapeco
Figura 26. Exemplo de fragmentação horizontal derivada
Essa técnica de fragmentação parece simples, mas deve se levar em conta que em
um grande modelo de banco de dados, as relações possuem ligação com mais de uma
relação, formando com isso mais de um fragmento derivado.
72
7.8
FRAGMENTAÇÃO VERTICAL
Segundo Özsu; Valduriez (2001) a fragmentação vertical é definida de acordo com as
aplicações que os usuários estão usando, consiste em particionar uma relação por seus
atributos.
EMPRESA
EMP_COD EMP_NOME
EMP_CNPJ
EMP_TEL
1
Expresso S. M
87.542.254/0001-20 323-1050
2
UnoChapeco
05.253.215/0001-55 323-2015
3
Coca-Cola
00.000.252/2253-22 362-2536
4
AMBEV
32.542.366/0001-23 586-3233
Figura 27. Exemplo de fragmentação vertical
Pode-se obter o seguinte fragmento a partir da relação empresa:
EMPRESA 3
EMP_COD EMP_NOME
1
Expresso S. M
2
UnoChapeco
3
Coca-Cola
4
AMBEV
Figura 28. Representação fragmentação horizontal
73
EMPRESA 4
EMP_CNPJ
EMP_TEL
87.542.254/0001-20
323-1050
05.253.215/0001-55
323-2015
00.000.252/2253-22
362-2536
32.542.366/0001-23
586-3233
Figura 29. Representação fragmentação horizontal
Neste caso a
partição criada a partir da relação empresa contém os atributos
EMP_COD e EMP_NOME mas poderia ser feito um particionamento com o número de
atributos necessários ao projeto. Tem-se uma particularidade na fragmentação vertical que
obriga que a relação resultante contenha todas as chaves primárias da relação proprietária,
tanto a fim de construir a relação original.
7.9
FRAGMENTAÇÃO HÍBRIDA
Em muitos casos apenas a fragmentação horizontal ou a fragmentação vertical são
suficientes para atender as necessidades de um determinado projeto, mas, em outros casos
necessitamos utilizar a fragmentação horizontal seguida da fragmentação vertical ou viceversa o que chamamos de fragmentação híbrida. Este tipo de particionamento é estruturado
em árvore, pois as duas estratégias são aplicadas uma após a outra formando assim uma
árvore de decisão. Este tipo de fragmentação também pode ser denominada de fragmentação
mista ou fragmentação aninhada.
74
R
R1
R1
R2
R1
R1
R1
Figura 30. Fragmentação híbrida
Em uma estrutura de fragmentação híbrida os níveis de aninhamento podem ser
grandes e variam conforme necessidade do projeto, porém, temos algumas regras a seguir,
no caso da fragmentação horizontal, deve-se parar quando cada fragmento consistir em uma
única tupla, já na fragmentação vertical o ponto de término é um atributo por fragmento.
7.10
REGRAS DE FRAGMENTAÇÃO
Para assegurar que os fragmentos manterão a consistência e o banco de dados não
sofrerá nenhuma mudança durante o processo de fragmentação, existem 3 regras básicas
que garante essas condições (ÖZSU; VALDURIEZ,2001):
Completeza: Quando fragmenta-se uma relação em N fragmentos, a completeza
garante que não haverá perda de dados, ou seja, será possível encontrar todos os dados da
relação global nos fragmentos, sendo que na fragmentação horizontal a completeza atua com
as tuplas e na fragmentação vertical com os atributos.
Reconstrução: a reconstrução garante que seja possível reconstruir uma relação
global a partir de seus fragmentos através de uma operação de álgebra relacional, garantindo
que sejam mantidas as restrições definidas sobre os dados.
No caso da fragmentação
horizontal a reconstrução é obtida através da operação de união e na vertical pela operação
de junção.
75
Disjunção: se uma relação for fragmentada horizontalmente em N fragmentos, os
dados de N1 não poderão estar em N2. Esse critério garante que a relação global está
disjunta. No caso da fragmentação vertical, a disjunção é definida sobre os atributos que não
fazem parte da chave primária, pois cada fragmento deve conter todas as chaves primárias da
relação global.
8
REPLICAÇÃO
Para Buretta (1997), “replicação é um serviço de administração da cópia, que através da
análise, implementação, administração e monitoramento de um serviço, garante a
consistência e segurança nas informações replicadas”, ou seja, é a cópia de informações de
um ou mais banco de dados para outro semelhante, depois das informações estarem
consistentes.
Pode-se citar algumas funcionalidades de um serviço de replicação:
•
Deve ser escalonável – habilidade para reproduzir volumes pequenos e grandes de dados
por gerentes de recursos heterogêneos.
•
Transformação de dados e serviços – cópias podem ser idênticas ou possuírem uma
semântica equivalente. Cópias idênticas teriam a mesma plataforma, mesmo conteúdo, e
os mesmos dados, cópias com semântica equivalente teriam as mesmas informações mas
plataformas diferentes e tipos de dados possivelmente diferentes.
•
Permitir replicação em ambos os modos, síncrona (tempo real) assíncrona (tempo não
real).
•
Possuir um mecanismo para descrever os dados e objetos a serem reproduzidos.
•
Prover um mecanismo para subscrever os dados e objetos disponíveis para replicação.
•
Prover um mecanismo para inicializar a réplica receptora.
•
Apoiar a administração fim-a-fim na segurança e qualidade nos serviços – garantir a não
corrupção dos dados ou objetos durante o processo de replicação. Em outras palavras os
dados podem mudar de formato, mas não em conteúdo.
•
Deve prover um mecanismo que registre qualquer fracasso durante o trabalho de
replicação.
•
Deve ter um suporte para recuperação automática. Este mecanismo prevê recuperação
depois de tipos específicos de fracassos.
•
Suporte para uma interface ao usuário, para monitorar e prover informações relativas ao
estado da replicação.
77
Há dois tipos básicos de replicação – SÍNCRONA E ASSÍNCRONA
8.1
REPLICAÇÃO DE DADOS SÍNCRONA
A principal característica da replicação síncrona é que a atualização acontece em
tempo real, ou seja, quando um dado é atualizado em uma base de dados o mesmo é
atualizado em todas as outras bases. A grande vantagem deste tipo de replicação é a alta
disponibilidade dos dados que são disponibilizados na hora para todas as bases.
Pode-se dizer que a replicação síncrona é provida de duas maneiras, ou por um
software de administração de banco de dados, ou por um gerente distribuído ou também
chamado de monitor de transações. As atualizações acontecem como uma unidade lógica de
trabalho, em outras palavras, é uma transação tudo ou nada.
8.2
REPLICAÇÃO DE DADOS ASSÍNCRONA
Segundo Burreta (1997), sempre há um grau de atraso entre a transação efetuada na
base e a atualização dos resultados desta transação nas réplicas. Na replicação assíncrona o
processo de replicação ocorre assíncrono a transação originada, ou seja, o período de
latência deve ser maior que zero.
A replicação assíncrona pode ser implementada da seguinte maneira:
Completa por atualização incremental – A atualização incremental é executada
definindo-se um período de tempo, por exemplo, a cada minuto, 10 minutos, a cada hora. Este
implica em processamento em lote.
Propagação delta de eventos – divide-se em dois tipos distintos de implementação,
ou seja, a propagação de eventos pode acontecer pela comunicação de banco de dadospara-banco de dados ou pela comunicação processo-para-processo. A propagação de
eventos implica em processamento temporal.
78
8.3
ATUALIZAÇÃO DAS RÉPLICAS
As formas de atualização das réplicas pode ser dividida em dois modelos; o modelo
master/slave (mestre/escravo) e o modelo update-anywhere.
8.3.1 Modelo mestre/escravo
Pode-se dizer que o modelo mestre/escravo tem como principal característica uma
unidade primária de distribuição dos dados podendo ser centralizada ou distribuída,
fragmentada ou não fragmentada. Sendo que desta unidades todos os dados são atualizados
para os demais sites. Segundo Buretta (1997, p. 44), só existe um único site atualizando a
cópia máster, assim não haverá possibilidade de conflito de atualização.
Também para Buretta, deste modelo são:
-
múltiplas cópias/réplicas de dados;
-
única fonte primária, chamada mestre;
-
as réplicas escravas possuem atributos somente de leitura com a
consistência de dados mantida por meio de um serviço de replicação
assíncrona.
8.3.2 Modelo update-anywhere
No modelo update-anywhere todo e qualquer site tem o mesmo direito de atualizar os
dados que são replicados em qualquer momento ao contrário do modelo mestre/escravo.
Pode se dizer que com isso os sites locais funcionam de forma autônoma. O modelo updateanywhere é mais difícil de se administrar, pois precisa conciliar conflitos de atualizações, isso
faz com que a arquitetura tenha suporte para detectar e mediar os possíveis conflitos de
atualizações simultâneas.
79
“Se a replicação síncrona for usada, um protocolo de efetivação em duas fases
é usado para garantir a consistência das réplicas ao longo da rede. Em outras
palavras, os dados de todas as réplicas estão sempre consistentes, porque
todas as alterações ocorrem sincronamente para todas as cópias por meio de
transações distribuídas. Se a replicação síncrona é usada, todas as
propriedades ACID são preservadas. Adicionalmente, transações distribuídas
concorrentes são serializadas por mecanismos de bloqueios, exatamente
como se fossem executadas localmente”. (BURETTA, 1997).
Se for utilizada a replicação assíncrona para este modelo, o isolamento das
transações, a partir de uma visão global do empreendimento, não pode ser garantido.
Localmente é possível garantir o isolamento, porém, as transações que acontecem em
paralelo não tem qualquer garantia que a transação use o estado mais atualizado do banco de
dados antes de fazer a próxima modificação. É muito complexo manter a consistência dos
dados com replicação assíncrona no modelo update-anywhere.
Segundo Buretta (1997, p. 45), dois tipos de conflitos de atualizações podem ocorrer:
conflitos entre tabelas e conflitos intra tabelas. Os conflitos entre tabelas ocorrem quando
existe relacionamento entre tabelas, geralmente através de chaves primárias e como
resultante de um projeto mau feito de particionamento ao longo dos sites. Este tipo de conflito
pode ocorrer independentemente de os dados estarem armazenados de forma redundante ou
não, como no modelo mestre/escravo.
Os conflitos intra tabelas ocorrem quando dados são armazenados de forma
redundante ao longo de múltiplos locais e a todo momento qualquer uma das réplicas é
considerada uma réplica atualizável. No caso da replicação assíncrona, ambos os tipos de
conflitos são detectados somente após ocorrerem e reparados através de operações manuais
ou por transações de compensação geradas pelo sistema, desfazendo as transações antes
que sejam efetivadas.
A aplicação de transações de compensação significa que algumas vezes as
atualizações executadas por uma transação não são duráveis, assim, o “D” das propriedades
ACID é violado. A perda desta propriedade gera um efeito replicante em que as transações
são subseqüentemente desfeitas, podendo ser visualizadas por outras transações antes que o
processo de decomposição – rollback – ocorra. Por sua vez, estas transações ditas
secundárias também requerem ações de compensação para garantir a consistência do banco
de dados, continuando-se este processo. BURETTA (1997, p. 46) diz também que usar
replicação assíncrona no modelo update-anywhere é como desabilitar todos os mecanismos
80
de bloqueio em um banco de dados centralizado. Recomenda também que este modelo
somente seja usado para sistemas de bancos de dados com um baixo grau de atualização,
implementando-se esquemas de distribuição que minimizem o número de atualizações das
réplicas, aplicando-se regras de integridade referencial e notificando aplicações quando
conflitos de atualização forem detectados, mesmo que processos de reconciliação estejam
disponíveis, fornecidos através do próprio gerenciador de banco de dados ou através de
processos implementados através da aplicação.
9
INTERBASE
O Banco de dados Interbase é uma ferramenta de gerenciamento de banco de dados
relacional baseado em uma arquitetura cliente/servidor. Um banco de dados relacional nada
mais é do que um conjunto de objetos que proporcionam o armazenamento de dados e sua
organização de modo a se tornarem informações completas, provendo de segurança e
integridade relacional e referencial entre os dados. Pode-se citar algumas características
deste gerenciador:
•
Concorrência em ambientes de leitura e gravação;
•
Flexibilidade no suporte a trigger;
•
Recuperação rápida em queda de servidores;
•
Gerenciamento de eventos mais fácil;
•
Opções de distribuição;
•
Suporte à várias plataformas (Sistemas operacionais);
•
Requisitos de servidores menores;
•
Baixa exigência de hardware;
O Interbase foi desenvolvido em meados de 1985 por uma equipe de engenheiros da
DEC (Digital equipament Corporation). Tendo como nome inicial Groton, desde então foi
sofrendo várias alterações até que finalmente em 1986 onde recebe o nome de Interbase,
iniciando na versão 2.0. Nesta época, a idéia era produzir um SGBDR (Sistema Gerenciador
de Banco de Dados Relacional) que oferecesse benefícios não encontrados em outros da
época.
Pode-se dizer que ao longo de seu desenvolvimento foram-se introduzindo muitas
características, entre elas pode-se citar: Acesso nativo a driver JDBC Commit automático de
duas fases;Sombreamento do Banco de Dados Replicação; Tratamento de Blob´s, Sistema de
Eventos, entre outros.
82
9.1
IBREPLICATOR
Replicar bases de dados significa, copiar dados alterados em uma fonte de dados a
uma ou mais base de dados de destino. Quando ocorre replicação significa que os dados
estão sincronizados em cada site, e isso não necessariamente significa que as bases de
dados de destino sejam idênticas e nem que os valores reais dos dados são os mesmos. Na
maioria dos casos as bases de destino são idênticas, mas existem situações em que
encontramos apenas algumas tabelas replicadas, e também podemos encontrar algumas
tabelas em que apenas parte dos dados são replicados.
A replicação é uma arquitetura que permite que a aplicação mantenha múltiplas cópias
dos dados. Isto é feito normalmente para melhorar o acesso aos dados, permitindo que cada
local da organização mantenha uma cópia dos dados, além de que, os dados de cada site
podem ser alterados e replicados a um ou mais sites. A replicação permite também a
atualização do dados para um único site mestre, ou seja, no caso deste trabalho a matriz da
empresa em questão onde são feitas as movimentações diárias dos dados.
Pode-se implementar diferente arquiteturas de replicação com o IBReplication são
elas:
•
Cópia simples da base de dados;
•
Modelo Import/Export;
•
Modelo Síncrono;
•
Modelo Assíncrono;
Os modelos de replicação já foram explicados no trabalho, porém no caso deste
trabalho iremos utilizar o modelo assíncrono de replicação de dados, sabendo da necessidade
da empresa em questão de atualização diária, porém não constante dos dados em sites
isolados.
O Interbase Replication consiste de um gerente de replicação e um servidor de
replicação, um gerente de replicação funciona em qualquer host de uma rede enquanto um
servidor de replicação irá funcionar somente na máquina em que a base de dados Interbase
83
estiver instalada fisicamente. O servidor de replicação é escrito em linguagem “C” e usado
diretamente em chamadas API’s do Interbase, isto significa que funciona em qualquer
plataforma de suporte do Interbase, e não necessita de nenhum middleware como BDE ou
ODBC para conectar-se ao Interbase. Para funcionamento da replicação o servidor de
replicação precisa saber quais linhas foram modificadas desde a última replicação, e precisa
ler cada linha alterada e mover os dados para a base de destino. Na prática, isto requer um
número razoavelmente grande de tabelas de definições dentro da base de dados de
configuração, bem como determinadas tabelas e gatilhos de cada base de dados a ser
replicada.
A base de dados de configurações possui informações como os nomes das tabelas,
campos chaves e campos de dados e possui também o nome, a posição, os usuários e as
senhas de todas as bases de dados envolvidas na replicação. Cada fonte de dados tem uma
tabela de registro definida REPL_LOG, toda vez que uma linha for inserida, alterada ou
deletada em uma tabela replicada, é inserido um registro nesta tabela gravando a ação feita
na tabela, bem como, o valor dos campos chaves, existe também um outro campo de
seqüência o qual assegura que as linhas sejam replicadas exatamente na mesma ordem que
foram modificadas. Isto é indispensável para integridade de transação e para o
relacionamento de chaves estrangeiras.
9.2
CONFIGURAÇÃO
Para configurar um banco de origem e destino para replicação deve-se criar um novo
projeto no IBReplicator com um nome especifico, este projeto vai criar um banco de dados de
configurações com as seguintes tabelas : config, database, licenses, publisheddb,
relationkeyfields,
relationreplifield,
relations,
relationsyncinfo,
repltimes,
schemata,
subscribeddb. Internamente cria-se um número de Schema que representa cada esquema
criado. Esse número é usado na criação de triggers em cada tabela replicada. Em esquemas
de replicação mais complexos, onde múltiplos BD de configurações podem ser usados,
sugere-se que cada banco de dados use um número diferente para que não haja conflitos.
Após a criação de um novo projeto de replicação o passo seguinte é adicionar as base
de dados de origem e destino, para isso deve-se informar o caminho da base com usuário e
senha de cada base de dados, o dialeto específico de cada banco a ser replicado, a prioridade
84
que servirá para a resolução de conflitos, como por exemplo quando se tentar inserir um
registro que já existe. Outros parâmetros de configurações que podem ser usados são: TIME
FIELD, que é usado para resolução de conflitos em time stamped.Este tipo de configuração
apenas será útil se todos os timestamps nos BDs forem confiáveis e contenham valores
corretos. Assume-se que todas as tabelas tenham um campo de timestamp com o mesmo
nome. RAS information: Se você quer que o IB Replicator ligue para uma outra máquina,
então preencha esses campos. O RAS name é o nome de uma conexão Dial Up do Windows,
com seu nome e senha. Se você não quer desligar a conexão após a replicação ter sido
executada, marque a opção ‘Keep Connection’.
O próximo passo é criar o esquema de replicação, começando com o tipo de que poder
ser “Priority based”
onde cada banco configurado possui uma prioridade previamente
informada para resolução de conflitos. Pode-se ter também um esquema de replicação “timestampd” no caso de bases com confiabilidade no time stamped, ou, um esquema de
replicação “master-slave” onde tem-se um banco configurado para ser mestre e um ou mais
bancos de dados para serem escravos, ou seja, apenas o banco mestre fará replicação para
os demais.
Com a definição das bases de origem e destino e com a escolha do esquema de
replicação a ser usado basta apenas definir quais serão as tabelas e procedures que serão
replicadas. Pode-se também definir quais são as chaves primarias de cada tabela e define-se
também quais os campos que serão replicados caso as tabelas não sejam idênticas. E
finalmente instruir o IBReplicator a criar os gatilhos necessários que serão utilizados para
replicar os dados entre as tabelas origem e destino.Tem-se agora apenas que rodar o
aplicativo RepliServer para iniciar a replicação.
9.2.1 Características adicionais
Logs do sistema são gerados para que se possa ter informações de cada evento de
replicação, como por exemplo, conexões, erros, keyvalues, estatísticas e comandos SQL. A
ferramenta
proporciona uma replicação com esquema de tempo pré-definido, ou seja, o
IBReplServer tem um intervalo de tempo que corresponde a um certo tempo em segundos
entre cada evento de replicação, no entanto você pode configurar as replicações para
ocorrerem de hora em hora, toda sexta-feira ou, no caso deste trabalho, todo o final do dia.
Para que o esquema de replicação ocorra normalmente deve-se iniciar o serviço scheduler,
85
que para o sistema operacional windows NT/2000 deve-se instalar o serviço, e em outros
sistemas apenas deve-se inicia-lo.
10
PROTÓTIPO
O presente capitulo como objetivo apresentar a problematização e a melhor solução
encontrada para o estudo de caso deste trabalho. Além de apresentar passo a passo a
solução proposta.
10.1
CONTEXTUALIZAÇÃO DO AMBIENTE
A Expresso São Miguel, empresa onde será aplicado este protótipo é uma empresa
composta por 59 agências, sua matriz esta localizada na cidade de Chapecó – SC, sua
atividade principal é o transporte de cargas e encomendas, com abrangência nos estados de
Santa Catarina, Paraná e Rio Grande do Sul.
A replicação utilizada pela empresa era feita através da metodologia de exportação e
importação de dados de arquivos texto, processo este controlado por um campo que contem a
data da última alteração feita nos registros. Este método de replicação é chamado DataStamp
porém sujeito a falhas a aplicação. Com a utilização das tecnologias utilizadas e com os
métodos aplicados na distribuição e replicação pretende-se eliminar alguns pontos falhos
deste sistema.
10.2
POR QUE DA DISTRIBUIÇÃO
Podemos dizer que com todo o embasamento teórico pesquisado até o presente
momento neste trabalho, existem muitas vantagens e desvantagem ao utilizarmos tecnologias
de suporte a replicação e distribuição de dados, porém, no caso Expresso São Miguel é viável
a aplicação dessas técnicas para manter um nível de confiabilidade, disponibilidade e
segurança nas aplicações utilizadas. Também por que a possibilidade de utilização da
tecnologia de banco de dados centralizado se torna inviável pela indisponibilidade de acesso
por meio de internet, e por que a maior parte dos tomadores destes serviços são terceiros e
não possuem outros vínculos com a empresa em questão, além da prestação de serviço.
Para o não comprometimento do seu negócio principal que é o transporte de cargas e
encomendas para do o sul do Brasil, a empresa Expresso São Miguel tem a necessidade de
manter réplicas distribuídas de seu banco de dados em cada ponto de atuação, isto para que
as suas transações e seus acordos com clientes e agenciadores possam ser mantidos com
extrema confidencialidade e segurança.
87
Com a implementação deste trabalho os dados atualizados ficaram disponíveis em
uma base de dados para que as agências e filias possam acessá-los no momento em que se
fizer necessário, ou então duas fases por dia já configurado no gerenciador. Ao contrário do
que é feito na atualidade onde os dados ficam disponíveis para a aplicação acessá-lo apenas
no final de cada dia. Também é importante salientar que o método utilizado hoje pela empresa
não dispõe de mecanismos de gerencia e segurança nas transações.
10.3
CRITÉRIOS USADOS PARA FRAGMENTAÇÃO
Com a presença de vários pontos de atuação denominado de agências, e com a
necessidade da disponibilização de dados em cada ponto, definimos então alguns critérios de
fragmentação para alocação dos dados. Como este é apenas um protótipo iremos apresentar
apenas um exemplo de cada critério utilizado para fragmentação, também sabendo alguns
critérios são indispensáveis para fragmentação de uma relação como: a completeza,
reconstrução e disjunção relembrando o conteúdo apresentado neste trabalho.
Foram aplicadas técnicas de fragmentação horizontais, devido ao fato de que as
agências/filias da empresa diferem apenas em relação aos seus clientes e locais de
atendimento. Com isso as tabelas dispostas na modelagem no anexo (anexo II), todas elas
estão disponíveis a todas as agências/filiais da empresa através de suas tuplas.
Algumas tabelas não possuirão nenhum tipo de fragmentação e apenas serão
replicadas na integra para cada site. Estas tabelas que não foram fragmentadas são as
tabelas que devem ser visualizadas em todos os sites sem nenhuma alteração, e as possíveis
alterações destas tabelas serão apenas no site mestre.
Este protótipo fará uso do método de replicação mestre/escravo onde o site principal
(mestre) que é representado pela matriz da empresa faz o papel de administrador de
replicação, ou seja, é neste site que esta disposto todas as regras de replicação. Os demais
sites são fragmentados de tal forma que cada site específico apenas tenha acesso a dados de
seu interesse como por exemplo à relação a seguir:
Tabela de Frete Peso
REG_COD FPE_ATEPESO
EMP_CODIGO CLI_CGCCP
FPE_VALOR
88
1
10
1
89221212000112
10,00
2
15
3
01225325000133
20,00
3
12
1
32225665000102
10,00
4
20
2
04256896000109
30,00
Figura 31. Tabela exemplo de fragmentação horizontal.
Na álgebra podemos representar através das seguintes sentenças:
R1 = σ < EMP_COD=1> (T_FRETEPESO)
R2 = σ < EMP_COD=2> (T_FRETEPESO)
R3 = σ < EMP_COD=3> (T_FRETEPESO)
Onde R1, R2 e R3 são respectivamente ilustradas nas figuras abaixo:
Relação R1
REG_COD FPE_ATEPESO
EMP_CODIGO CLI_CGCCP
FPE_VALOR
1
10
1
89221212000112
10,00
3
12
1
32225665000102
10,00
A relação R1 contém todos os registro da tabela T_FRETEPESO com a cláusula emp_código
igual a “1”.
Relação R2
REG_COD FPE_ATEPESO
4
20
EMP_CODIGO CLI_CGCCP
2
04256896000109
FPE_VALOR
30,00
A relação R2 contém todos os registro da tabela T_FRETEPESO com a cláusula emp_código
igual a “2”.
Relação R3
REG_COD FPE_ATEPESO
EMP_CODIGO CLI_CGCCP
FPE_VALOR
89
2
15
3
01225325000133
20,00
A relação R3 contém todos os registro da tabela T_FRETEPESO com a cláusula emp_código
igual a “3”.
A partir das relações acima dividimos a tabela de frete peso em fragmentos baseados em
suas tuplas.
10.4
PROJETO GLOBAL
No projeto global temos a presença de todas as relações na sua integra e o conjunto
de todos os dados atualizados, pode-se chamar também de site mestre, ou seja, este site
contém todos as regras de replicação, e é nele que são feitas as alterações nos registros que
serão replicados. O modelo global pode ser visualizado no anexo I e vale salientar que este
modelo é apenas um protótipo do modelo real que por opção da empresa não pode ser
apresentado neste trabalho.
10.5
PROJETOS LOCAIS
O modelo local é a divisão do modelo global em partes menores, ou seja, é o modelo
global depois da fragmentação, cada fragmento do modelo global é uma base de dados de
uma agência/filial e é atualizado a partir do modelo global. Podemos visualizar um protótipo do
modelo local no anexo II.
10.6
CONFIGURAÇÃO DA REPLICAÇÃO
Por se tratar de um modelo de replicação mestre/escravo, todas as configurações da
replicação são feitas no site mestre, sendo que é este que coordena a replicação para os
demais sites.
Ao criarmos um mecanismo de replicação utilizando IBReplicator o primeiro passo é a
criação de um banco de dados de configurações, como pode-se observar na figura 32 e 33 os
parâmetro de configuração das bases de dados, este banco de dados não contém as regras
de replicação mas é nele que encontramos dados como por exemplo, os sites que iremos
replicar, quais os usuários de replicação que também se encontra neste banco dados como
90
quais tabelas serão replicadas e quais são as chaves de cada tabela, quais os atributos serão
replicados no caso de fragmentação vertical e o tempo de disparo para cada replicação.
Figura 32. Tela de configuração de Base de Dados.
91
Figura 33. Base de dados de configurações.
Neste exemplo temos a presença da base global e da uma base local, o campo
Descriptive name refere-se ao nome da base de dados, Server é o caminho da base que
estamos nos referindo, no caso de uma base remota coloca-se o endereço de IP da máquina
na referência e o caminho do banco de dados. Adiministrative user name é no nome do
administrador da replicação e sua respectiva senha no campo que segue Adminitrative
password. Após deve-se especificar o dialeto do banco, que para banco criados a partir do IB
6.0 é 3 e no caso de bases criadas com IB 5X é 1. O campo Priority é muito importante pois
especifica o nível de prioridade de cada banco de dados. Isso é utilizado na resolução de
conflitos, como por exemplo, quando se tentar inserir um registro que já existe.
Após a definição das bases de dados a serem replicadas o próximo passo é a criação de
um esquema de replicação que será utilizado na figura 34 abaixo.
92
Figura 34. Criando um esquema de replicação.
De um duplo click no ícone Edit Defaut Settings para marcar a opção
“Conflict
resolution” para garantir que seu esquema de replicação resolva os problemas de conflitos
conforme a configuração de cada bando de dados. Também marcar as opções de criação de
logs de connection, Erros, Key Values e Statistics.
Com estas configurações pode-se adicionar o banco de origem o banco de dados de
origem, ou seja, o banco de dados mestre. Estendendo a treeview até que aparecer os
campos de banco de dados de destino e de origem, click no BD origem e de um dublo click
no ícone add souce database do lado direito.
Informa-se então o banco de dados de origem da replicação e seu respectivo usuário e
senha para replicação conforme mostra figura 35 abaixo.
93
Figura 35. Tela de configuração da base de dados de origem.
Temos algumas configurações ao selecionarmos o BD de origem como: a estratégia
de resolução de conflitos, ou seja, o método de replicação a ser utilizado que no nosso caso
escolhemos a opção Master/slave onde o banco de dados de origem tem todos os privilegio
de alteração como mostra a figura 36.
94
Figura 36. Tela de definição do esquema de replicação.
O próximo passo é selecionar a/as bases de destino e definir quais as tabelas que
serão replicadas e como isso vai ser feito conforme figura 37. De um duplo click no campo
Generate tables, keys e fields então verá a tabela de auto definição. Esta opção só pode ser
utilizada se as tabelas de origem e destino tem a mesma estrutura e todas tenham chaves
primárias definidas. Click no botão generate e todas as suas tabelas origem e destino serão
configuradas.
95
Figura 37. Esquema de replicação
Agora precisa-se instruir o IBRelpManager para criar todos os triggers necessários que
serão utilizados para replicar os dados entre as tabelas origem e destino. Alguns exemplos de
triggers criados poderão ser vistos no anexo III deste trabalho. Pode-se então rodar o
IBRelpServer para iniciar a replicação.
O IBReplServer tem um intervalo de tempo que corresponde a um certo tempo em
segundos entre cada evento de replicação, no entanto você pode configurar as replicações
para ocorrerem de hora em hora, toda sexta-feira ou duas fezes ao dia que será neste caso.
Como mostra a figura abaixo.
96
Figura 38. Configuração do intervalo de replicação
Esta é à parte de configuração, é claro que isto não basta para se ter um sistema de
banco de dados distribuído e replicado, além disso, tudo temos que acompanhar e fazer o que
chamamos de administração da replicação, fazendo consultas a logs e usando de ferramentas
de monitoramento da replicação.
10.7
SOBRE O SISTEMA
O sistema é composto de quatro modelos envolvidos diretamente com a replicação
dos dados e distribuição dos dados, Módulo Agência que é onde necessita os dado
atualizados para emissão dos controles de frete, Módulo Faturamento que é onde o sistema
recebe diariamente o maior volume de dados para movimentação, Módulo Financeiro que é
onde os movimentos são realizados e Módulo Comercial responsável pela alimentação das
informações de tabelas de fretes.
Os módulos Faturamento, Comercial e Financeiro estão situados na Matriz da
empresa em um único banco de dados, ou seja, em um único local fisicamente, este banco
de dados principal contém todas os dados agrupados também chamado de modelo global.
Com relação a base de banco de dados, estão envolvidos dois modelos de dados
diferentes, o modelo local e o modelo global. No modelo local cada filial da empresa possui
97
um conjunto de dados específico e o modelo global também chamado de Mestre contém
todos os dados centralizados. Para suportar esta comunicação a empresa optou por adquirir
um link IPTurbo de 256kb e um sistema de replicação síncrono com o banco de dados
principal, ou seja, todas as transações realizadas internamente são replicadas para uma
segunda base de dados que está na internet e esta sim administra a replicação para as
demais bases localizados em pontos diferente. A base de dados principal é administrada
internamente e apenas dados relevantes as filias são disponibilizados para a replica, sendo
assim a necessidade de comunicação diminui, e o tráfego de rede e processamento
conseqüentemente diminui também.
O esquema proposto pode ser mais bem visualizado na figura 39 abaixo:
Site1
Site 4
Rede de
Site 2
Comunicação
Site 3
Figura 39. Esquema de distribuição proposto.
11
CONCLUSÃO
Ao iniciar o desenvolvimento deste trabalho, algumas dificuldades foram encontradas,
entre elas o modelo de fragmentação e alocação a ser utilizado? Como deveria ser a
replicação e com qual periodicidade deveria acontecer? Qual gerenciador de banco de dados
utilizar? Entre outras questões que envolvem as regras de negocio da empresa onde será
implementado o protótipo.
Com embasamento teórico proposto neste trabalho, contendo assuntos referentes a:
sistemas distribuídos, redes de computadores, banco de dados, sistemas gerenciadores de
bancos de dados, banco de dados distribuídos e replicação, pode-se ter as repostas
necessárias para desenvolvimento do modelo proposto, sendo de extrema importância tanto
para desenvolvimento do esquema de alocação e distribuição do banco de dados como para o
método de replicação dos dados.
Conclui-se com este trabalho que a utilização das tecnologias pesquisadas são de
extrema importância tanto para empresa em questão, como para a região e para o meio
acadêmico, dando suporte para novos trabalhos como para a pesquisa em outros
gerenciadores utilizando novas técnicas e para a empresa a satisfação de resolver um
problema que poderia comprometes ate mesmo o seu principal negócio.
Com a implementação destas tecnologias para disponibilização dos dados para as
agências da empresa, tem-se uma maior confiabilidade nas operações realizadas. Também,
pode-se dizer, que com os testes realizados tanto por parte do sistema gerenciador de banco
de dados (SGBD) como pelo sistema de replicação, constatou-se que as ferramentas suprem
a necessidade da empresa.
O protótipo passou a ser aplicado como projeto piloto na empresa e teve que se fazer
um investimento consideravelmente baixo, porém, terá um enorme retorno com a eliminação
de falhas na comunicação entre seus pontos de atuação trazendo assim maior agilidade e
confiabilidade na elaboração de seus serviços.Porém no caso de outras transportadoras este
modelo deverá sofrer adequações para melhor adaptação.
12
TRABALHOS FUTUROS
Os Sistemas de banco de dados distribuídos estão cada vez mais sendo utilizados
pelas corporações e com isso o surgimento de novas tecnologias, para tanto um sistema
deste tipo deve ser administrado da melhor maneira possível em busca da melhor
configuração. Como projetos futuros para este sistema sugere-se a aplicação de ferramentas
de gerenciamento de replicação e controle de acesso objetivando o monitoramento das
transações.
Com o uso de sistema de administração de banco de dados pode-se obter
informações como, por exemplo, locação com maior acesso a dados, consultas de maior
custo, horários de maior uso da rede para replicação entre outras informações que podem ser
utilizadas para otimização da replicação. Com acesso a estas informações podem-se criar
novos esquemas de replicação e distribuição do banco de dados para que se tenha um
aumento de performance desejado.
Também podem ser criados novos esquemas de replicação para outros sistemas que
a empresa utiliza com suas filias como o sistema de compras e o sistema de frota que fazem o
controle de compras, requisições de mercadoria e o controle da frota respectivamente. E a
utilização de novas tecnologias tanto da parte de gerenciadores de banco de dados como na
área de redes de comunicação como, por exemplo, a utilização de uma rede privada de
dados.
Este trabalho é uma colaboração importante para outros projetos da banco de dados
distribuídos, podendo ser referencia para implementação também de Data Mining, Data
Warehouse e Banco de dados moveis.
13
REFERÊNCIAS
BELL, David; GRIMSON, Jane. Distributd Database Systems. Addison-Wesley Publishing
Company,,1992
BUYYA, R. High Performance Cluster Computing: Architecture and Systems, vol 1. pags 345, New Jersey: Prentice Hall, 1999.
COULOURIS G.; DOLLIMORE J.; KINDBERG T. Distributed Systems Concepts and
Design. 3.ed. Harlow, England: Addison Wesley, 2001.
DATE, C. J.. Introdução a sistemas de Banco de Dados. Tradução da 4ª ed.,
Rio de Janeiro: Campus, 1991.
DIETZ, Hank LINUX Parallel Processing HOWTO, 1998 [online]. Disponível em:
<http://yara.ecn.purdue.edu/~ppLINUX/PPHOWTO/pphowto.html>. Acesso em: marco de
2004.
EMMERICH W. EngineeRING Distributed Objects. Chichester: John Wiley & Sons Ltd,
1999.
FRIEDRICH, Luiz Fernando Curso
Santa Catarina Florianopolis – SC.
de Sistemas de Distribuido, Universidade Federal de
GALLI, D.L. Distributed Operating Systems Concepts and Practice. New Jersey: Prentice Hall,
1998.
MELO, Rubens N.; SILVA, Sidney Dias da,
TANAKA, Asterio K., Banco de
Dados em Aplicações Cliente-Servidor.
Rio de Janeiro: Livraria e Editora
Infobook S.A., 1998.
MYRICOM
Myrinet
Overview,
2001
Disponível
<http://www.myri.com/myrinet/overview/index.html>. Acesso em: marco 2004.
em:
OMG – Object Management Group. The Common Object Request Broker: Arc hitecture and
Specification, Rev 2.3 OMG Inc., Framingham, Mass., March 1998.
ÖZSU, M. Tamer; VALDURIEZ, Patrick. Princípios de Sistemas de Banco de Dados
Distribuídos. Tradução da 2ª ed., Rio de Janeiro: Campus, 2001.
RADAJEWSKI, J., EADLINE D. Beowulf HOWTO. 1998. [online] Disponível
em:<http://www.LINUXvoodoo.com/howto/HOWTO/Beowulf-HOWTO/Beowulf-HOWTO4.html>. Acesso em: marco de 2004.
STALLINGS, W. Operating Systems Internals and Design Principles. 3.ed. New
Jersey:Prentice -Hall, 1998.
TANENBAUM, Andrew S. Redes de Computadores. Rio de Janeiro: Campus, 1997.
TANENBAUM A. S. Sistemas Operacionais Modernos, Rio de Janeiro: Prentice-Hall do
Brasil Ltda, 1995.
101
TANEMBAUM, Andrew S. & STEEN, Maarten van. “Distributed Systems: Principles and
Paradigms”, Prentice Hall, 2002, p.803.
VERÍSSIMO, Paulo & RODRIGUES, Luiz. “Distributed Systems forSystems Architect”, Kluwer,
2001, 623p.
HEUSER, Carlos Alberto. Projeto de banco de dados. 3ª ed.,Porto Alegre: Sagra Luzzato,
1999.
SILBERSCHATZ, Abrahan; KORTH, Henry F.;
SUDARSHAN S.. Sistema de Banco de
Dados. Tradução da 3ª ed., São Paulo: Makron Books, 1999.
RAMAKRISHNAN, Raghu. Database Management Systems. USA,Boston: McGRAW-HILL
INTERNATIONAL EDITIONS, 1997.
BURRETA, Marie; Data Replication Tools and Tecnologies for Managieng
14
ANEXOS