Bases de Dados Distribuídas - Dei-Isep

Bases de Dados Distribuídas
Projecto do 5º Ano da Licenciatura em Engenharia Informática
Ramo de Computa do re s e S iste mas
Ana be la da Costa V ie ira
Orientador: Alexandre B ragança
Setembro de 2002
Bases de Dados Distribuídas
Agradecimentos
Antes de tudo, quero agradecer aos meus pais por me terem ensinado o valor
do trabalho e do estudo e à minha família (principalmente à minha irmã) pelo apoio
que sempre me deu. Quero também agradecer ao Paulo Sousa pelo apoio e
compreensão.
Para a realização deste trabalho não posso deixar de agradecer ao Engº
Alexandre Bragança pela sua orientação e preocupação em indicar o caminho certo;
ao Engº Miguel Oliveira pela sua disponibilidade a fornecer informações (não
conseguiria fazer o exemplo prático sem a sua ajuda!) sempre que surgiam dúvidas.
iii
Bases de Dados Distribuídas
Índice
AGRADECIMENTOS .......................................................................................................................................III
ÍNDICE.....................................................................................................................................................................V
ÍNDICE DE FIGURAS .....................................................................................................................................VII
ÍNDICE DE TABELAS ..................................................................................................................................VIII
1. INTRODUÇÃO ....................................................................................................................................................1
1.1. Introdução...............................................................................................................................................1
1.2. Estrutura do Relatório...........................................................................................................................2
2. BASES DE DADOS DISTRIBUÍDAS...................................................................................................................5
2.1. Antecedentes das Bases de Dados Distribuídas................................................................................5
2.2 Definição de Bases de Dados Distribuídas...................................................................................... 11
2.3. Regras de uma Base de Dados Distribuída.................................................................................... 17
2.4. Replicação e Fragmentação de Dados............................................................................................ 21
2.4.1. Replicação de Dados........................................................................................................................22
2.4.2 Fragmentação de Dados ....................................................................................................................28
2.4.3. Alocação...........................................................................................................................................34
2.5 Gestão distribuída de transacções .................................................................................................... 35
2.5.1 Protocolos de segurança....................................................................................................................37
2.5.2 Controlo de Concorrência.................................................................................................................39
2.6 Processamento distribuído de questões............................................................................................ 42
2.6.1 Passos do processamento distribuído de questões ............................................................................44
2.7 Bases de Dados Distribuídas Móveis................................................................................................ 51
2.8 Recentes avanços na tecnologia das BDD ....................................................................................... 58
3. O M ICROSOFT SQL SERVER.........................................................................................................................63
3.1 Replicação no Microsoft SQL Server................................................................................................ 64
3.2 Fragmentação no Microsoft SQL Server ......................................................................................... 67
3.3 Transacções no Microsoft SQL Server ............................................................................................. 70
3.4 Processamento Distribuído de Questões no Microsoft SQL Server ............................................ 71
4. O CASO GIS M EDIADORES ...........................................................................................................................73
5. CONCLUSÕES ..................................................................................................................................................79
BIBLIOGRAFIA ................................................................................................................................................. 81
GLOSSÁRIO ........................................................................................................................................................ 83
ÍNDICE REMISSIVO........................................................................................................................................ 85
v
Bases de Dados Distribuídas
SIGLAS .................................................................................................................................................................. 87
ANEXOS ................................................................................................................................................................ 89
A1 - CORBA ................................................................................................................................................. 89
A2 - COM ..................................................................................................................................................... 93
A3 - ODBC ................................................................................................................................................... 98
A4 - X Open DTP ........................................................................................................................................ 99
A5 - Regras de Transformação Algébrica............................................................................................101
vi
Índice de Figuras
FIGURA 1 : O RGANIZAÇÃO DE UM SISTEMA DE GESTÃO DE FI CHEIROS ......................................................................5
FIGURA 2 : O RGANIZAÇÃO DE UMA BASE DE DADOS ...................................................................................................7
FIGURA 3 : A FLEXIBILIDADE DE FU NCIONAMENTO DA ARQUITECTURA CLIENTE / SERVIDOR ...................................8
FIGURA 4 : CONFIGURAÇÕES REPRESENTATIVAS DOS SISTEMA S CLIENTE / SERVIDOR ..............................................9
FIGURA 5: A ARQUITECTURA FÍSICA DE UMA BDD ...................................................................................................12
FIGURA 6 – DEADLOCK GLOBAL: NENHUM NÓ O CONSEGUE DETECTAR UTILIZANDO APENAS .................................20
FIGURA 7 : MÉTODO CONSENSUAL DE QUORUM ........................................................................................................27
FIGURA 8 : GRÁFICO DE J OIN PARTICIONADO...........................................................................................................31
FIGURA 9 : EXECUÇÃO DE UMA TRANSACÇÃO DISTRIBUÍDA .....................................................................................35
FIGURA 10 : PROTOCOLO 2PC ..................................................................................................................................37
FIGURA 11 : FASES DO TWO-PHASE L OCKING ............................................................................................................40
FIGURA 12 : ÁRVORE DE ANÁLISE ALG ÉBRICA..........................................................................................................45
FIGURA 13 : ÁRVORE DE ANÁLISE ALG ÉBRICA REESTRUTURADA .............................................................................46
FIGURA 14 : O PTIMIZAÇÃO DE UM INQUÉRITO SEGUINDO A PR IMEIRA REGRA DE REDU ÇÃO...................................47
FIGURA 15 : ÁRVORE DE ANÁLISE ALG ÉBRICA..........................................................................................................48
FIGURA 16 : EXEMPLO DO TIPO DE CÉLULAS EXISTENTES NUMA REDE MÓVEL ........................................................53
FIGURA 17: MODELO DOS O BJECTOS DA RELAÇÃO O BRA -EMPREGADOS ...............................................................60
FIGURA 18 : DIFERENTES TIPOS DE REPLICAÇÃO EM TERMOS DE AUTONOMIA DOS NÓS E CONSISTÊNCIA
TRANSACCIONAL..............................................................................................................................................67
FIGURA 19 : PUBLICAÇÕES EXISTENTE S NO SERVIDOR .............................................................................................74
FIGURA 20 : PROPRIEDADES DE UMA PUBLICAÇÃO ...................................................................................................75
FIGURA 21 : O REPLICATION C ONFLICT VIEWER AJUDA À VISUALIZAÇÃO DOS CONFLITOS EXISTENTES DURANTE A
FASE DE JUNÇÃO DAS BDS. ..............................................................................................................................76
FIGURA 22 : ARQUITECTURA DO MODELO DE REFERÊNCIA DA OMG.....................................................................89
FIGURA 23: ARQUITECTURA CORBA ORB .............................................................................................................90
FIGURA 24: CLIENTE A UTILIZAR UMOBJECTO COM ATRAVÉS DE UM APONTADOR PARA UM INTERFACE............94
FIGURA 25: O BJECTO COM RELÓGIO ......................................................................................................................95
FIGURA 26: TRÊS MÉTODOS PARA ACEDER A OBJECTOS COM ................................................................................96
FIGURA 27 : ARQUITECTURA DO ODBC ...................................................................................................................98
FIGURA 28: INTERACÇÕES ENTRE CLI ENTE, TM AND SERVIDOR COM O PROTOCOLO X-OPEN DTP ..................100
FIGURA 29 : ÁRVOR E DE ANÁLISE ALGÉBRICA ......................................................................................................102
FIGURA 30: ÁRVORE DE ANÁLISE ÁLGÉBRICA .......................................................................................................103
Bases de Dados Distribuídas
Índice de Tabela s
TABELA 1 : TABELA EMPREG
DA FIRMA DE C ONSTRUÇÃO C IVIL .........................................................................21
TABELA 2 : TABELA CARGO....................................................................................................................................22
TABELA 3 : TABELA LOCALIZACAO ....................................................................................................................22
TABELA 4 : TABELA OBRA.......................................................................................................................................22
TABELA 5 : FRACCIONAMENTO HORIZONTAL DA TABELA DE EMPREGADOS ..........................................................28
TABELA 6 : FRACCIONAMENTO VERTICAL DA TABELA DE EMPREGADOS ...............................................................28
TABELA 7 : FRACCIONAMENTO MISTO DA TABELA DE EMPREGADOS .....................................................................29
TABELA 8 : FRAGMENTAÇÃO DERIVADA DA TABELA OBRA ....................................................................................29
TABELA 9: Nº DE INQUÉRITOS EFECTUADOS POR NÓ.................................................................................................33
TABELA 10: MATRIZ DE UTILIZAÇÃO DE ATRIBUTOS................................................................................................33
TABELA 11: INICIALIZAÇÃO DA MATR IZ DE AFINIDADES ENTRE ATRIBUTOS ...........................................................33
TABELA 12 : ALGORITMOS DE OPTIMIZAÇÃO DE INQUÉRITOS DISTRIBUÍDOS ..........................................................49
TABELA 13: PRODUTOS BDD E SUAS CARACTERÍSTI CAS MAIS IMPORTANTES..........................................................64
viii
Introdução
1. Int roduç ão
1.1. Introdução
Este relatório debruça-se sobre “Bases de Dados Distribuídas”. Mas, porquê
este tema? Estamos num sociedade de informação e, para armazenar essa mesma
informação, devemos ter bases de dados seguras, fiáveis e permanentemente
disponíveis. Existem milhares de empresas a nível mundial. Quando existe uma fusão,
que alternativas temos? Inutilizar uma das bases de dados, copiando apenas a sua
informação para a outra? Nos dias que correm, isso seria impraticável; logo, a melhor
solução é juntá- las de uma maneira o mais transparente possível para o utilizador
final.
Com este relatório pretende-se, além de lançar alguma luz sobre um tema tão
vasto (e em constante alteração com os avanços nesta área), apresentar uma solução
possível para um caso concreto, no âmbito da empresa I2S SA – Informática,
Sistemas e Seguros.
A I2S é uma empresa que nasceu em 1984 com o objectivo de criar soluções
informáticas para a actividade seguradora e que se tem vindo a implantar no mercado
com o GIS (Gestão Integrada de Seguros), uma solução flexível, global e integrada.
O GIS divide-se em vários módulos, entre eles o GIS Mediadores. Este
módulo é um interface de gestão de seguros contendo vários sub- módulos, integráveis
consoante as necessidades do mediador de seguros. Entre estes podemos referir o submódulo da carteira, cuja finalidade é a gestão de apólices e propostas de seguro e o
sub- módulo da cobrança, cuja finalidade é a gestão dos recibos das apólices e sua
liquidação. Integrada no GIS Mediadores existe uma base de dados que contém os
dados necessários para o mediador poder trabalhar. As condições de trabalho dos
mediadores de seguros são muito peculiares: podem trabalhar para apenas uma ou
mais seguradoras em agências tipicamente distantes da sede da seguradora. Por
1
Bases de Dados Distribuídas
exemplo, um mediador tem a sua sede em Lisboa, uma filial de média dimensão no
Porto e depois, espalhados pelo país, uma série de escritórios de sub-mediadores. Aqui
põe-se o problema: como manter actualizadas quer a base de dados da sede, quer a da
filial, quer as dos vários sub-mediadores? Temos também de ter em atenção que o
mediador pode não precisar de ter informação sobre todos os clientes da seguradora,
mas apenas sobre aqueles com os quais lida. Provavelmente, também não precisará de
toda a informação de que a seguradora dispõe, bastando- lhe alguns dados mais
importantes. E se o mediador tiver apenas um portátil como ferramenta de trabalho?
No final deste documento, o objectivo será ter alcançado uma solução possível
e viável para um caso tão desafiador.
1.2. Estrutura do Relatório
Por razões de lógica e ordem de ideias começaremos por ver conceitos de
Bases de Dados Distribuídas 1 , suas vantagens e desvantagens. O problema da
replicação de dados será alvo de especial atenção, assim como a fragmentação e
alocação de dados, a gestão distribuída de transacções e a optimização de inquéritos
distribuídos. Também serão abordados os mais recentes avanços, nomeadamente a
mobilidade das bases de dados (possível com o advento dos portáteis), e o modelo
orientado ao objecto.
Seguidamente, iremos comparar alguns sistemas de BDD. O Microsoft SQL
Server, o Oracle Server e a Sybase são alguns exemplos. Como representante das
BDD orientadas ao objecto, mencionar-se-á a Objectivity DB. O Microsoft SQL
Server estará em maior destaque, devido à enorme disseminação que tem tido nos
últimos anos2 , sendo que a maioria das empresas as utiliza, e os clientes do GIS
Mediadores não serão, certamente, uma excepção.
Um cenário possível de distribuição de dados será depois apresentado em
maior pormenor como exemplo da interligação de várias delegações e agentes
dispersos geograficamente. Tentar-se-á também apresentar uma proposta de solução
para esse mesmo cenário.
No final, serão apresentadas as conclusões atingidas.
1
De agora em diante serão designadas por BDD.
2
Ao qual o facto de esta tecnologia ser da patente da Microsoft não será alheio.
2
Introdução
3
Bases de Dados Distribuídas
4
Bases de Dados Distribuídas
2. Bases de Dados Di st ribu íd as
2.1.
Antecedentes
das
Bases
de
Dados
Distribuídas
Nos dias que correm, a informação é considerada o bem mais precioso de uma
organização. Informação permanentemente actual, correcta e relevante contribui para
uma maior competitividade, o que, num mundo empresarial com níveis de
concorrência nunca antes atingidos, pode significar a diferença entre o lucro e o
prejuízo. Para além das características da actualidade, da correcção e da relevância, a
informação deve estar sempre disponível e interpretável, para que possa fazer parte do
processo de tomada de decisão de um modo eficaz.
As Bases de Dados actuais (ainda de um ponto de vista centralizado) tiveram
como antecessores os sistemas de gestão de ficheiros. Estes foram a primeira
abordagem para a resolução do problema da existência de enormes quantidades de
dados numa organização. Tinham por objectivo automatizar algumas tarefas
realizadas manualmente até aí. Porém, os processos eram executados quase da mesma
forma.
Figura 1 : Organização de um sistema de gestão de ficheiros 3
3
M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -
www.csse.monash.edu.au/courseware/cse5200
5
Bases de Dados Distribuídas
Estes sistemas encontravam-se demasiado próximos dos fluxos de informação
das organizações (onde o mesmo documento pode ter vários processamentos
diferentes), e como resultado, os mesmos dados podiam ser armazenados em ficheiros
diferentes e recolhidos em alturas diferentes e por diferentes aplicações. As
incoerências e as redundâncias tornaram-se inevitáveis. Os problemas adicionais de
manutenção destes sistemas ao nível das aplicações e do acesso aos dados ditou a sua
substituição pelas Bases de Dados 4 .
Ao contrário do que sucede num sistema de ficheiros, os dados de uma BD são
organizados num único conjunto. Além disso, o acesso físico à BD é feito por um
Sistema de Gestão de Base de Dados 5 , e as aplicações têm apenas uma interface
lógica com este SGBD. Um SGBD é um conjunto de software destinado a gerir todo
o armazenamento e manipulação dos dados do sistema, fazendo a interface entre o
nível aplicacional e a BD propriamente dita.
Os termos “relacional”, “rede” ou “hierárquica” referem-se ao modo como o
SGBD organiza a informação internamente, organização essa que afecta a velocidade
e a flexibilidade com que o utilizador acede à informação. A BD armazena também,
além dos dados, a sua descrição (metadados) num dicionário de dados que ajuda a
interpretar a estrutura dos dados armazenados, disponibilizando ao nível aplicacional
uma interface lógica.
A modelação de dados é uma actividade fundamental para a tecnologia das
BDs. O seu objectivo é tentar encontrar um modelo que traduza a estrutura lógica dos
dados e, ao mesmo tempo, que satisfaça os requisitos de informação destes sistemas.
Os diagramas E-R são uma abordagem largamente difundida para ajudar à criação do
modelo conceptual de dados. Estes explicitam de uma forma clara as entidades
existentes no sistema e as relações entre elas, juntamente com as suas cardinalidades.
4
De agora em diante serão designadas por BD.
5
De agora em diante serão designadas por SGBD
6
Bases de Dados Distribuídas
Figura 2 : Organização de uma base de dados 6
A evolução seguinte foi a arquitectura cliente / servidor, que surgiu com a
possibilidade de interligação de computadores pessoais em rede (LAN). Falamos já,
portanto, de um modelo não centralizado. A característica fundamental destes
sistemas é a divisão do processamento global entre as máquinas-cliente, responsáveis
pelas tarefas de front-end com os utilizadores (ou seja, que correm o nível
aplicacional), e as máquinas-servidor, responsáveis pelas tarefas de gestão e
manipulação da BD.
A relação entre os processos cliente e servidor é mostrada na figura 3. Um
utilizador pode invocar um processo cliente (seleccionando um link num Web
browser, por exemplo) e envia um pedido a um processo servidor (seta nº 1). Se o
servidor está configurado para responder a esse pedido, pode fazê-lo directamente
(seta nº 2). Alternativamente, o pedido do cliente original pode envolver pedidos
adicionais a outros servidores (seta nº 3): por exemplo, informação a ser extraída de
uma BD localizada noutro ponto. Assim, um software servidor pode tornar-se um
software cliente, recebendo respostas de outros servidores secundários (seta nº 4).
Outra opção seria o servidor invocar uma aplicação local para que esta respondesse a
um pedido de serviço (seta nº 5), tal como refrescar uma BD ou enviar um e-mail e
depois enviar os resultados (seta nº 6). Outros serviços, ainda, podem ser pedidos
(seta nº 7), e o respectivo retorno será enviado para outros clientes (seta nº 8).
7
Bases de Dados Distribuídas
1
CLIENTE
APLICAÇÃO
1
22
88
SERVIDOR
CLIENTE
55
3
77
SERVIDOR
66
3
44
SERVIDOR
Figura 3 : A flexibilidade de funcionamento da arquitectura cliente / servidor 7
Ao contrário dos sistemas tradicionais, a comunicação entre clientes e
servidores não tem estados – o servidor não precisa de ter consciência do cliente que
lhe está a enviar o pedido. Este tipo de comunicação (sem o estabelecimento de
conexões) representada pelas setas na figura anterior é utilizada na Internet e fornece
uma vasta gama de opções de design aos gestores da info rmação.
A estrutura cliente/servidor, o funcionamento da Internet e a grande variedade
de protocolos servidores que entretanto foram disponibilizados, oferecem uma grande
flexibilidade ao desenho e implementação de sistemas de informação poderosos. Uma
representação desta gama de escolhas é representada na Fig. 2.4. O cliente de cada
uma das cinco possibilidades de implementação de design fornece o interface (Gestão
do Interface) de cada sistema. Do mesmo modo, o servidor fornece serviços de dados
(Gestão de Dados), desde documentos estáticos até resultados de um inquérito à base
de dados. Dependendo das necessidades específicas de cada aplicação, componentes
adicionais podem ser incluídos, quer no cliente quer no servidor, para alcançar
determinadas lógicas de comunicação e facilidades de gestão de dados ou de
interface. As setas bidireccionais mais pequenas representam comunicação com
representação de estados entre os sistemas componentes, tal como a que pode ocorrer
num único host. As setas maiores representam comunicação sem representação de
estados via Internet.
6
M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -
www.csse.monash.edu.au/courseware/cse5200
8
Bases de Dados Distribuídas
Numa BDD, como se pode depreender pela figura, a gestão dos dados é
dividida entre o servidor e o cliente, enquanto a lógica da aplicação e a gestão do
interface são da inteira responsabilidade deste último. No outro extremo estão os
sistemas distribuídos, onde os servidores gerem os dados, a lógica da aplicação e uma
parte do interface, enquanto o cliente apenas tem de gerir uma outra parte do
interface.
LADO CLIEN TE
GESTÃO DO
GESTÃO DO
GESTÃO DO
GESTÃO DO
GESTÃO DO
INTERFACE
INTERFACE
INTERFACE
INTERFACE
INTERFACE
LÓGICA DA
LÓGICA DA
LÓGICA DA
APLICAÇÃO
APLICAÇÃO
APLICAÇÃO
5
GESTÃO
4
DOS DADOS
GESTÃO DO
3
INTERFACE
2
1
LÓGICA DA
LÓGICA DA
LÓGICA DA
APLICAÇÃO
APLICAÇÃO
APLICAÇÃO
GESTÃO
GESTÃO
GESTÃO
GESTÃO
GESTÃO
DOS DADOS
DOS DADOS
DOS DADOS
DOS DADOS
DOS DADOS
LADO SERVIDOR
BASES DE
GESTÃO
LÓGICA
APRESENTAÇÃO
SISTEMAS
DADOS
REMOTA DE
DISTRIBUÍDA
REMOTA
DISTRIBUÍDOS
DISTRIBUÍDAS
DADOS
Figura 4 : Configurações representativas dos sistemas cliente / servidor 8
7
Jeff R.Wright, German Gavilan, Yiguo Zhang e Kamie Redinbo in Emerging Technologies for
Developing Distributed Database Systems – http://bridge.ecn.purdue.edu/~yiguo/dropbox/w2000.pdf
8
Ensor e Stevenson, 1997, in Jeff R.Wright, German Gavilan, Yiguo Zhang e Kamie Redinbo in
Emerging
Technologies
for
Developing
Distributed
Database
Systems
–
http://bridge.ecn.purdue.edu/~yiguo/dropbox/w2000.pdf
9
Bases de Dados Distribuídas
Em determinada altura no tempo começou-se a perceber que as máquinas não
precisavam de ser apenas clientes e servidores, mas pares que podem colaborar no
cumprimento de determinadas tarefas. Foi a partir desse momento que o termo BDD
se difundiu. Uma BDD é então, um conjunto de vários servidores de BDs que podem
funcionar autonomamente, mas também em colaboração com outros servidores de
SGBD remotos, pedindo e/ou fornecendo dados e mantendo-os consistentes.
De entre as razões que levaram à utilização de BDDs destacam-se, então, as
seguintes:
?
Desempenho melhorado – Considere-se uma rede com 10 postos e um
servidor. As 10 estações podem processar, cada uma, 10 milhões de instruções
por segundo (MIPS) e o servidor pode processar 25 MIPS. Usando o modelo
centralizado estaríamos a desperdiçar a maior parte dos 100 MIPS de poder de
computação dos postos. Adicionando mais postos, apenas pioraríamos o
problema, pois mais postos significam uma maior carga para o servidor, sem
adicionar recursos utilizáveis. Esta arquitectura rapidamente se transforma
num gargalo de performance;
?
Reflectir o estado distribuído de uma organização – no caso de organizações
espalhadas por zonas geograficamente distantes, com necessidade de uma
coordenação comum;
?
Por necessidades de crescimento – quando a dimensão e o crescimento de
algumas organizações invalidam a possibilidade de colocar toda a BD numa
mesma máquina;
?
Natureza distribuída de algumas aplicações;
?
Maior disponibilidade e confiabilidade – já que não dependemos de uma única
BD);
?
Permitir a partilha de dados enquanto se mantém algum controlo local;
?
Devido ao aparecimento de novos paradigmas e novos modelos – WWW
fornecedores de serviços distribuídos, Java, CORBA...
Uma nova arquitectura tem emergido, em contraponto às BDDs: a arquitectura
em cluster. Esta difere da arquitectura das BDDs num aspecto fulcral, o acesso à base
10
Bases de Dados Distribuídas
de dados em si, às suas tabelas. Um cluster é constituído por vários servidores, uma
rede e um subsistema de discos partilhados. Não há necessidade de replicação ou
fragmentação, uma vez que os dados estão à disposição de todos os nós. Existe apenas
um dicioná rio de dados e uma única imagem do sistema, comum a todos os seus
elementos. Um cluster é, portanto, mais fácil de gerir do que uma BDD, porém, se os
nós se encontrarem geograficamente distantes, o acesso aos dados pode tornar-se
muito lento. A outra alternativa seria instalar uma rede de comunicação dedicada de
(talvez) centenas ou milhares de quilómetros: algo impraticável, afinal.
2.2 Definição de Bases de Dados Distribuídas
O que é, então, uma Base de Dados Distribuída?
No livro de José Luís Pereira, Tecnologia de Bases de Dados, pode ler-se:
“Por definição, uma base de dados distribuída é um sistema de bases de dados cujos
dados se encontram fisicamente dispersos por várias máquinas, ligadas por meios de
comunicação, mas integrados logicamente”.
Segundo a Prof. Isabel M. Besembel Carrera, da Universidade dos Andes, na
Venezuela (sistemas.ing.ula.ve), “uma BD distribuída é uma colecção de várias BDs
logicamente interrelacionadas sobre uma rede de computadores. Os utilizadores têm
acesso integrado e transparente a uma colecção de BDs (1980). Actualmente, uma
BDD é uma colecção de BDs independentes ou federadas, onde cada sistema tem
facilidades para partilhar dados e serviços com os outros membros”.
Já na Webopedia.com, “uma BDD consiste em dois ou mais ficheiros de dados
localizados em diferentes locais de uma rede de dados. Porque a BD é distribuída,
diferentes utilizadores podem aceder a ela sem interferirem uns com os outros. No
entanto, o SGBD deve periodicamente sincronizar as BDs espalhadas de maneira a
que os dados permaneçam consistentes.”
Estas três definições focam alguns dos aspectos mais importantes das BDDs,
como a localização dispersa dos dados, a fragmentação e duplicação dos mesmos, o
controlo de acessos, entre outros.
11
Bases de Dados Distribuídas
Os termos “BDs logicamente interrelacionadas” ou “dados integrados
logicamente” devem ser bem vincados. Os dados contidos nas várias BDs devem ser
estruturados, isto é, fariam sentido se estivessem numa única BD centralizada. De
facto, um conjunto de páginas Web em diferentes máquinas, mas contendo material
sobre um determinado assunto, não pode ser considerado uma BDD, porque os seus
dados são, no máximo, semi-estruturados.
Os diferentes nós que constituem a BDD devem ser autónomos, isto é, devem
ser capazes de executar programas, e operações e transacções na BD sem suporte
externo.
Também, se não existirem transacções globais (transacções que envolvem
mais do que um nó), a BDD não pode ser considerada como tal, mas apenas como
uma colecção de BDs ligadas por uma rede.
Figura 5: A arquitectura física de uma BDD
Para melhor se poder compreender a tecnologia das BDD, importa, primeiro,
dividir os sistemas de BDD em duas classes: homogéneas e heterogéneas.
Na primeira classe, todos os nós utilizam o mesmo SGBD e têm as mesmas
aplicações instaladas, fazendo lembrar um único sistema de BD, mas em que os dados
estão armazenados em vários repositórios ligados por meios de comunicação. O
12
Bases de Dados Distribuídas
design do tipo top-down está intimamente ligado a estes sistemas. Como é lógico, é
mais usual, ao fazer o desenho dos sistemas a partir do nada, considerar-se que todas
as máquinas serão idênticas. Estas classes de BDD podem oscilar entre vários graus
de autonomia local. Este termo indica o modo como o sistema parece trabalhar, a
partir da perspectiva dos utilizadores e dos programadores. Tome-se como exemplo
um sistema com pouca ou nenhuma autonomia, onde todos os pedidos são enviados
para um nó central, chamado gateway. Daqui, estes são enviados para o nó que
contém a informação ou para a aplicação requerida. Esta situação ocorre com alguma
frequência na Internet, nos sites “espelho” de localizações populares para aumentar a
velocidade de acesso, já que vários nós podem conter a mesma informação e as
mesmas aplicações, de forma a melhorar o fluxo e os tempos de acesso. A
desvantagem do gateway é que este tem de possuir uma conexão à rede bastante larga
e muito poder de processamento para conseguir satisfazer os pedidos e os
encaminhamentos dos dados dos nós para os utilizadores.
Já nos sistemas heterogéneos, os nós utilizam SGBDs diferentes. Estes tanto
podem ser baseados no mesmo modelo de dados, como em modelos de dados
diferentes. Duas organizações diferentes (que a dado ponto da sua história se juntam)
dificilmente utilizarão o mesmo esquema de armazenamento dos dados; por isso, a
abordagem bottom-up está mais ligada a estes sistemas. Também, para incorporar
sistemas legados, esta abordagem é a mais indicada. Aqui, os nós têm um grau de
autonomia muito maior: cada um tem os seus utilizadores, aplicações e dados locais e
lida com estes sozinho, apenas se ligando aos restantes nós para obter informação que
não possui. Este tipo de BDD é muitas vezes chamado de sistema federado ou
federação.
Para que seja possível integrar BDs distintas numa federação de modo a existir
interoperabilidade, ou seja, ser possível trocar informação entre sistemas, redes e
aplicações heterogéneas, existem três abordagens:
-
Utilização de database gateways / middleware – quando existem SGBDs
diferentes, mas baseados no mesmo modelo de dados;
-
Integração num modelo global – quando os SGBDs se baseiam em
modelos de dados diferentes;
-
Objectos distribuídos – utilizando o modelo OO (Orientado ao Objecto).
13
Bases de Dados Distribuídas
Utilização de database gateways / middleware
Os database gateways fazem traduções entre formatos de dados e comandos
das várias implementações, permitindo que cada SGBD “veja” os outros como seus
iguais. Tem como limitações a não existência de suporte para a gestão de transacções
não- locais (ou seja, permitem consultar os dados sob a gestão de outro SGBD, mas
não permitem actualizá- los) e o facto de não ter em consideração as diferenças
existentes entre os esquemas das BDs envolvidas (não havendo homogeneização ao
nível dos esquemas individuais).
A utilização de middleware esconde do nível aplicacional as especificidades
de cada SGBD, uniformizando a interface com os servidores de BDs. Alguns
exemplos de middleware são o ODBC, o IDAPI e o X Open DTP. Por fornecerem a
cada aplicação um conjunto único de funções para aceder a vários servidores de BD,
têm como grandes vantagens a portabilidade e a simplicidade, porém, raramente têm o
desempenho e a funcionalidade das APIs próprias de cada servidor de BD.
Integração num modelo global
A técnica é criar uma camada sobre os vários sistemas de BDs componentes,
dando a ilusão de um sistema homogéneo. Alguns exemplos deste método são o
esquema unificado e a multibase de dados. Na primeira abordagem, é utilizado um
modelo suficientemente rico, capaz de integrar os restantes modelos, para fazer a
integração dos esquemas de BDs participantes num único esquema unificado e global.
Já na solução multibase de dados não se procura um esquema global às BDs
participantes; pelo contrário, cada BD local opera de forma autónoma e independente,
existindo, no entanto, capacidade de cooperação entre si.
Objectos distribuídos
Os sistemas são construídos recorrendo a conjuntos de objectos previamente
desenvolvidos, que são, depois, interligados por forma a obter as funcionalidades
pretendidas.
Para
que
os
objectos
possam
trocar
mensagens
entre
si,
independentemente da linguagem de programação em que foram criados, do sistema
operativo da máquina em que residem e da sua localização na rede, é necessário
estabelecer mecanismos que proporcionem essa transparência. Existem duas
14
Bases de Dados Distribuídas
propostas: a DCOM e a CORBA. A DCOM (Distributed Component Object Model) é
uma proposta da Microsoft Corp. que fornece uma base para a partilha de objectos,
independentemente da linguagem em que estes foram desenvolvidos. A CORBA
(Common Object Request Broker Arquitecture) é da responsabilidade da OMG e
define uma interface – Object Request Broker (ORB) – cujos serviços, numa
perspectiva cliente / servidor, permitem que um objecto cliente aceda aos serviços de
um objecto servidor sem que o primeiro necessite de saber detalhes do segundo,
proporcionando, assim, um acesso transparente entre objectos distribuídos.
As BDs devem ter os seus dados protegidos, quer de acidentes naturais
(incêndios ou inundações), quer de acessos não autorizados, modifiquem eles ou não
o seu conteúdo. Nas BDDs, apesar dos dados replicados fornecerem um certo nível de
backup (melhorando o primeiro aspecto da segurança), o problema de controle de
acessos torna-se mais complexo, devido à distribuição desses mesmos dados.
Uma das primeiras questões é onde permitir o acesso aos dados: no nó de
origem do pedido ou no nó remoto? A primeira estratégia tem a seu favor a
simplicidade; porém a probabilidade de acessos não autorizados aumenta, já que o
utilizador mal- intencionado precisa unicamente de conseguir aceder a uma máquina.
A segunda estratégia é mais segura, mas também tem várias desvantagens, a começar
desde logo pelo processamento adicional que é necessário. Alé m disso, é necessário
manter tabelas de acesso, o que é computacionalmente caro, e, replicar as passwords
aumenta o risco de estas serem obtidas, apesar de encriptadas.
Uma terceira estratégia consiste em responsabilizar servidores de perfis por
permitir o acesso aos dados. Estes estão organizados em rede e quando um dos
servidores receber um pedido de acesso, todos os membros desta rede determinam se
devem autorizar ou não o acesso. Woo e Lam9 (os estudiosos que desenharam esta
solução) pensam que separar o sistema de acessos do interface da aplicação reduz as
possibilidades de ocorrerem problemas.
9
Thomas Woo e Simon Lam, Authorization in Distributed Systems: A Formal Approach, 1992 in
Steven P. Coy, Security Implications of the Choice of Distributed Database Management System
Model: Relational vs. Object-Oriented, informação disponível no site
http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper072_073_074/SCO_.PDF
15
Bases de Dados Distribuídas
Para impedir que alguns utilizadores tenham acesso a certos dados, apesar de
terem acesso ao sistema, foi criado o mecanismo das vistas. Apesar de as vistas serem
eficientes em termos de impedimento do acesso a dados restritos, o seu uso pode
introduzir muito overhead, principalmente no caso das vistas globais (que necessitam
de obter dados de vários nós). Para definir que dados podem ser incluídos na vista,
todos os dados da BD devem receber uma classificação de acesso. Esta classificação
pode ser dependente de:
o Tipo: a classificação é determinada com base nos atributos associados
aos dados;
o Valor: a classificação é determinada com base no valor dos dados;
o Nível da origem: a classificação dos dados é equivalente à da sua
origem;
o Etiqueta da origem: é dada uma classificação arbitrária aos dados, ou
pela sua origem, ou pelo utilizador que os introduziu.
Uma solução apresentada por Thuraisingham e Ford 10 , que introduz pouco
overhead na verificação das permissões, utiliza dois motores de inferência, um para os
inquéritos e outro para as actualizações. Este último verifica as restrições de
segurança da BD à medida que mudam as condições de segurança nos dados. O motor
de inferência do processamento de inquéritos avalia as entidades pedidas pelo
inquérito, os dados libertos durante um determinado período que estão ao nível de
segurança dos inquéritos, e os dados relevantes disponíveis externamente que estejam
no mesmo nível de segurança. A isto chama-se a base de conhecimento. O
processador avalia as potenciais inferências que resultam da união da base de
conhecimento com as potenciais respostas ao inquérito. Se o nível de segurança do
utilizador for superior aos níveis de segurança de todas as potenciais inferências, a
resposta é permitida.
Esta técnica apenas pode ser utilizada em BDDs homogéneas. Nas BDDs
heterogéneas, seria necessário que os motores de inferência para cada tipo de SGBD
10
Bhavani Thuraisingham e William Ford, Security Constraint Processing in A Multilevel Secure
Distributed Database Management System, 1995, in Steven P. Coy, Security Implications of the Choice
of Distributed Database Management System Model: Relational vs. Object-Oriented, informação
disponível no site http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper072_073_074/SCO_.PDF
16
Bases de Dados Distribuídas
verificassem as restrições de segurança de todos os dados locais, o que se tornaria
proibitivo em termos de overhead introduzido.
2.3. Regras de uma Base de Dados Distribuída
Para uma BD ser considerada verdadeiramente distribuída deve obedecer a
uma série de regras, chamadas as 12 regras de Date:
Regra 0:
Para o utilizador, um sistema distribuído não se deve distinguir de um sistema
não distribuído
1. Autonomia local
2. Inexistência de um nó central
3. Disponibilidade permanente
4. Localização transparente
5. Fragmentação transparente
6. Duplicação transparente
7. Processamento distribuído de questões
8. Gestão distribuída das transacções
9. Transparência do hardware
10. Independência do sistema operativo
11. Independência das tecnologias de rede
12. Independência do SGBD
Regra 1: Autonomia local
Os nós devem ser o máximo possível autónomos. Os dados locais são geridos
localmente, sob responsabilidade local; as operações locais devem permanecer
puramente locais. Todas as operações de um dado nó são controladas por esse nó;
nenhum nó deve depender de outro para funcionar correctamente.
Porém, existem situações em que alguma perda de autonomia é inevitável.
17
Bases de Dados Distribuídas
Regra 2: Inexistência de um nó central
Não deve existir nenhum nó “central” para nenhum serviço central, que
obrigasse a que todo o sistema estivesse dependente desse nó. As razões de ser desta
regra são simples: esse nó central poderia ser um bottleneck, e o sistema estaria
vulnerável. Sendo assim, o processamento de questões, a gestão de transacções e o
controlo de concorrência (entre outras funções) devem estar distribuídas.
Regra 3: Disponibilidade permanente
Nunca deveria existir a necessidade de fazer um shutdown planeado a todo o
sistema. Alterações na arquitectura da rede, por adição de novos nós ou remoção dos
existentes, assim como falhas em alguns nós não devem impedir os restantes de
continuarem a sua operação, se não total, pelo menos, parcialmente. Também deve ser
possível criar e destruir fragmentos e réplicas de fragmentos dinamicamente e deve
ser possível fazer um upgrade do SGBD num dos nós sem fazer parar todo o sistema.
Regra 4: Localização transparente
Os utilizadores não precisam de saber onde os dados estão guardados
fisicamente: estes devem comportar-se, pelo menos de um ponto de vista lógico,
como se os dados estivessem guardados no nó local. Esta característica vem facilitar o
desenvolvimento e manutenção de sistemas, fornecendo aos utilizadores e a todo o
nível aplicacional em geral, a facilidade de utilizar “questões genéricas”, deixando
para o SGBD a tarefa de resolver os detalhes de navegação na rede. Desta forma,
aplicações e utilizadores não são afectados por qualquer alteração na localização dos
dados.
Regra 5: Fragmentação transparente
Um sistema distribuído suporta fragmentação de dados se uma dada relação
puder ser dividida em vários “bocados” ou fragmentos para armazenamento físico.
Uma divisão bem estruturada dos dados pelas várias localizações físicas
permite uma optimização do desempenho da BDD. Os dados que são mais utilizados
numa localização física devem estar aí guardados para poupar tempo de acesso à rede.
Os utilizadores devem continuar a “ver” uma só tabela lógica.
18
Bases de Dados Distribuídas
Existem três tipos de fragmentação: horizontal, vertical e mista. A
fragmentação horizontal (SELECT) divide uma tabela separando os registos, ou seja,
cada uma das novas tabelas tem o mesmo esquema da tabela original. A fragmentação
vertical (PROJECT) divide a tabela separando as colunas, ou seja, os esquemas das
novas tabelas são subconjuntos da tabela original. A fragmentação mista utiliza uma
combinação destas duas.
Regra 6: Duplicação transparente
Este conceito é normalmente designado por replicação e também é
importantíssimo para a optimização do desempenho da BDD: dados que, por razões
de prevenção, desempenho ou disponibilidade dos dados, estão duplicados em
localizações físicas diferentes, devem ser periodicamente sincronizados. No entanto,
os utilizadores devem poder trabalhar como se os dados não estivessem replicados.
Regra 7 : Processamento distribuído de questões
Como os dados estão dispersos pelos vários nós da rede, pode ser necessário
efectuar questões de um modo distribuído, ou seja, o processamento da questão pode
necessitar da cooperação de vários nós. Todo esse processo é coordenado pelo sistema
sem intervenção dos utilizadores. Uma boa estratégia de processamento distribuído de
questões é muitíssimo importante para a BDD.
O processamento de questões num sistema distribuído envolve:
-
tempo de CPU local e actividade de I/O em vários nós diferentes;
-
algumas comunicações de dados entre estes nós.
A quantidade de comunicações é um factor que, obviamente, pesa muito no
desempenho.
Regra 8 : Gestão distribuída das transacções
Dois aspectos principais na gestão de transacções, o controlo da concorrência
e o controlo da recuperação de falhas, necessitam de mais atenção num ambiente
distribuído, isto porque uma só transacção pode envolver a execução de código em
múltiplos nós e, portanto, múltiplos updates. Assim, diz-se que cada transacção é
constituída por vários “agentes”, onde um agente é o trabalho realizado para uma
determinada transacção num determinado nó.
19
Bases de Dados Distribuídas
Mantém o lock
Nó X
do recurso RX
T1 X
T2 X
Espera que T1 X liberte RX
Espera que
Espera que
T1 Y acabe
T2 X acabe
T1 Y
T2 Y
Nó Y
Espera que T2 Y liberte RY
Mantém o lock
do recurso RY
Figura 6 – Deadlock global: nenhum nó o consegue detectar utilizando apenas
informação interna a esse nó.
Regra 9 : Transparência do hardware
Independentemente da plataforma de hardware, os utilizadores devem ver
apenas uma imagem única do sistema. É desejável que se possa correr o mesmo
SGBD em diferentes plataformas de hardware e que essas plataformas participem
como iguais (onde apropriado) num sistema distribuído.
Regra 10 : Independência do sistema operativo
É também desejável que, além de correr o mesmo SGBD em diferentes
plataformas, se possam correr diferentes sistemas operativos – até mesmo diferentes
sistemas operativos no mesmo hardware. De um ponto de vista comercial, os
ambientes de sistemas operativos mais importantes – e portanto, aqueles que o SGBD
deve suportar – são, entre outros o UNIX, o OS/2, o MS/DOS e o Windows.
Regra 11 : Independência das tecnologias de rede
É obviamente desejável que o SGBD suporte uma variedade de diferentes
redes de comunicações. Do ponto de vista do SGBD distribuído, a rede é meramente o
fornecedor de um serviço seguro de transmissão de mensagens. É considerado um
20
Bases de Dados Distribuídas
serviço seguro aquele que recebe mensagens do nó X e as entrega ao nó Y apenas
uma vez, pela mesma ordem que foram enviadas, não as misturando.
Regra 12 : Independência do SGBD
Um sistema distribuído ideal deve suportar diferentes SGBD de um modo que
seja transparente para o utilizador.
2.4. Replicação e Fragmentação de Dados
Estes dois conceitos, apesar de diferentes, estão intimamente ligados quando
se trata do desenho de uma BDD. Depois de obtido o design da fragmentação, é
necessário estudar a melhor localização para cada fragmento (alocação) e se será ou
não necessário replicar cada um deles. Estas decisões devem ser tomadas tendo em
vista a melhor performance global possível para todas as aplicações, pesando factores
tais como a performance do sistema, os custos, a tolerância a falhas de nós individuais
e da rede.
Para melhor exemplificar estes dois conceitos, será apresentado um pequeno
exemplo: uma empresa de construção civil que resolveu modernizar-se e pretende
distribuir a sua BD. Nesta existem, entre outras, uma tabela EMPREG com o código,
nome, código do cargo, código da localização da área de residência e código da obra
(onde se encontra a trabalhar no momento) dos empregados; uma tabela CARGO com
o código, nome e salário correspondente a cada cargo; uma tabela LOCALIZACAO
com o código e nome de localizações e, finalmente, uma tabela OBRA com o código,
nome e código de localização de cada obra.
CODIGO
NOME
LOCALIZACAO
CARGO
OBRA
1
F. Rodrigues
1
4
1
2
J. Barros
2
4
2
3
A. Silva
3
3
1
4
J. Sousa
1
2
3
5
M. Pereira
2
1
1
Tabela 1 : Tabela EMPREG da firma de Construção Civil
21
Bases de Dados Distribuídas
CODIGO
NOME
SALARIO
1
mestre-obras
€ 1500
2
carpinteiro
€ 1200
3
electricista
€ 1300
4
servente
€ 800
Tabela 2 : Tabela CARGO
CODIGO
LOCALIZACAO
1
Porto
2
Lisboa
3
Coimbra
Tabela 3 : Tabela LOCALIZACAO
CODIGO
NOME
LOCALIZACAO
ORCAMENTO
1
Lote 2
1
€300.000.00
2
Loja 34
3
€500.00.00
3
Moradia 76
2
€100.000.00
Tabela 4 : Tabela OBRA
2.4.1. Replicação de Dados
A replicação é a técnica de duplicar dados em vários nós diferentes. As razões
que podem tornar desejável esta duplicação são, basicamente, as seguintes:
-
Prevenção contra falhas: a falha de um nó que contenha dados vitais ao
sistema não compromete, necessariamente, o seu funcionamento;
22
Bases de Dados Distribuídas
-
Redução da transferência de dados: há uma maior probabilidade de os
dados estarem disponíveis localmente ou mais perto do nó que os requisita.
Desta maneira, são reduzidos os custos da sua transferência, quer em
termos de exploração dos meios de comunicação, quer em termos de
tempo consumido;
-
Paralelismo : os inquéritos à base de dados podem ser processados por
vários nós em paralelo (maior desempenho).
Porém, também existem desvantagens que se prendem com o facto de ser
necessário manter a coerência global do sistema. De facto, quando a informação num
nó é actualizada, as suas réplicas também o devem ser, o que aumenta o overhead do
sistema (custos de actualização e necessidade de algoritmos complexos para a
execução de transacções). A replicação é mais vantajosa em sistemas onde haja
muitas leituras a dados, mas poucas actualizações.
Um pormenor de implementação importante tem a ver com a localização física
das réplicas. Um conjunto de réplicas é identificado por um nome lógico e cada
réplica individual por um nome físico. Por exemplo: o ficheiro fich1.DB existe na
BD, no nó X. Quando esse ficheiro é replicado no nó Y, passam a existir dois
ficheiros com os seguintes caminhos físicos: X/fich1.DB e Y/fich1.DB. A aplicação
cliente apenas tem de saber o nome lógico para aceder ao ficheiro, sendo da
responsabilidade do SGBD manter um catálogo de réplicas que forneça o
mapeamento dos nomes físicos e respectivas localizações.
Dependendo de quando as actualizações são propagadas, a replicação pode ser
síncrona ou assíncrona. A replicação síncrona faz as actualizações às réplicas do
item de dados dentro de uma única transacção. Este tipo de replicação também é
chamado de eager replication (replicação esfomeada, numa tradução literal). Quando
é feito o COMMIT à transacção, todas as réplicas estão no mesmo estado e têm os
mesmos valores. Assim, a transacção apenas pode ser finalizada com sucesso se as
réplicas forem alteradas com sucesso. O modelo assíncrono actualiza apenas uma das
réplicas numa transacção e propaga as alterações para as outras réplicas mais tarde,
23
Bases de Dados Distribuídas
em outra transacção. Este tipo de replicação também é chamado lazy replication
(replicação preguiçosa).
Quando é indispensável que exista consistência estrita (os dados têm de estar
permanentemente actualizados), é necessário usar a replicação síncrona. Se não for
esse o caso, deve utilizar-se a replicação assíncrona por ter melhores tempos de
resposta. É possível até indicar intervalos de tempo para que as actualizações tenham
lugar, de hora em hora, por exemplo.
2.4.1.1 Me c anis mos de ac tualizaç ão
Existem vários tipos de mecanismos de actualização, diferindo nos
pormenores de onde as actualizações são feitas, das permissões dos clientes e do
timing das actualizações.
?
primary copy (também chamada primary site replication);
?
update everywhere (também chamada shared ownership ou, em
português, replicação simétrica);
?
Epidémica – as operações são feitas numa única réplica (uma qualquer)
e uma transacção diferente compara os dados das outras réplicas,
actualizando-as;
?
Subscrição – semelhante à anterior, mas considera-se que os nós
apenas querem ter os dados, não se importando com a sua consistência.
Os nós que desejem manter a sua réplica actualizada devem
subscrever-se perante o nó responsável pelos dados. Um nó que não se
tenha subscrevido, é responsável por tentar obter os dados a partir de
qualquer um dos outros nós, mas é possível que esses dados não sejam
os mais recentes.
?
ROWA (read one, write all) – como o nome indica, nas operações de
escrita, as réplicas são sincronizadas e actualizadas ao mesmo tempo.
Como todas as réplicas estão sincronizadas, é possível ler apenas uma
delas, obtendo uma leitura consistente.
24
Bases de Dados Distribuídas
As duas primeiras técnicas são as mais difundidas, apresentando-se em maior
pormenor de seguida. A técnica da subscrição é a adoptada pelo SQL Server e será
mais aprofundada no terceiro capítulo.
Na replicação por primary copy um dos nodos detém a posse dos dados,
sendo o único que os pode actualizar e propagar essas actualizações para os nodos
onde estão as suas réplicas – denominadas snapshots). Este método funciona da
seguinte maneira:
-
Primeiro, é necessário escolher a réplica do item de dados que irá ser a
primary copy. O nó que contém a réplica é chamado primary site.
Diferentes items de dados podem ter diferentes primary sites. O primary
site deve ser escolhido de modo a que seja o que acede mais vezes a estes
dados, ou o que lhes aceda mais dificilmente (devido, por exemplo, a uma
ligação de rede com uma baixa taxa de transferência de dados).
-
Quando uma transacção necessita de fazer um lock ao item de dados Q,
pede o lock do primary site de Q. Implicitamente, é obtido o lock de todas
as réplicas do item de dados.
A vantagem deste método é a sua simplicidade, já que dados replicados são
tratados de um modo semelhante aos dados não replicados. Por outro lado, o primary
site pode tornar-se um gargalo para o desempenho de um grande sistema: são
enviados para este nó os pedidos de leitura provenientes de nós que não tenham
réplicas destes dados, e todos os pedidos de escrita. Apesar de os pedidos de leitura
poderem ser realizados em paralelo por nós com réplicas, o processamento dos
pedidos de escrita são todos feitos por este nó.
Existe uma variante deste tipo de replicação, a dynamic ownership. A
autorização para actualizar dados replicados vai-se movimentando entre os nós, mas
apenas um dos nós possui a autorização em cada momento.
Na replicação simétrica, qualquer réplica pode ser actualizada a qualquer
momento, até mesmo em simultâneo, propagando-se o efeito dessas actualizações, de
forma sincronizada ou não, para as restantes réplicas. Este método pode dar origem a
conflitos entre actualizações, o que acontece quando duas ou mais transacções tentam
25
Bases de Dados Distribuídas
actualizar os mesmos dados em duas ou mais réplicas distintas simultaneamente.
Formas de resolução destes conflitos incluem, por exemplo, o recurso ao factor
tempo, em que prevalece a actualização mais recente.
Para além de mecanismos de actualização incluídos na kernel da BD, existem
mecanismos que podem ser utilizados em BDs já existentes, como é o caso do Bengal.
Este sistema foi construído recorrendo à tecnologia COM da Microsoft (garantindo,
assim, a sua portabilidade) e pode ser utilizado em BDs relacionais tais como a
Sybase SQL Anywhere, Oracle e Microsoft SQL Server. Aqui, o ênfase é colocado
nos utilizadores móveis remotos e é utilizada replicação assíncrona, optimista, com
ajuda de servidores de reconciliação especiais.
Reconciliação é uma técnica para resolver o problema de a mesma réplica ser
actualizada por dois nós diferentes, com dados contraditórios. O item de dados tem o
timestamp da última actualização; a réplica que pretende actualizar este item de dados
tem dois timestamps, um novo e um mais antigo (correspondente à anterior
actualização dos dados). Se este último valor e o timestamp do item de dados forem
iguais, então a actualização é segura: os dados são alterados e é colocado no item de
dados o timestamp que a réplica contém, senão, a réplica tem de ser reconciliada.
2.4.1.2 Re plic aç ão e To le rânc ia a F alhas
Existem duas estratégias de replicação:
Gossip (“Boato”) – as actualizações são propagadas assincronamente a todas
as réplicas, uma a uma. Ou seja, são enviadas simples mensagens a todos os nós onde
existam réplicas;
Comunicação de Grupo – é feito um multicast/broadcast das actualizações a
todas as réplicas ao mesmo tempo. É necessário ter em atenção que o broadcast não é
possível nas WANs.
Por vezes, não é possível actualizar todas as réplicas. Em ambientes realistas,
temos também de contar com a possibilidade de existirem falhas, quer dos nós, quer
da rede de comunicações. A melhor maneira de lidar com falhas nos nós é ignorá- las.
26
Bases de Dados Distribuídas
Existem, no entanto, métodos para corrigir a falta de actualizações de réplicas em nós
que falharam ou que deixaram de estar disponíveis devido a uma falha na rede.
Um deles é o protocolo de quorum, mais propriamente, o protocolo consensual
de quorum. Neste método, cada cópia tem um peso associado e um número de versão.
Que o peso total de todas as cópias seja N, que o quorum de leitura seja Qr e o de
escrita Qw. Estes dois últimos valores devem respeitar as seguintes restrições:
2*Qw > N
e
Qr + Qw > N
Cada leitura deve fazer lock a um número de réplicas cuja soma dos pesos seja
maior ou igual a Qr, e será lida a réplica com o maior número de versão. Cada escrita
deve fazer lock a um número de réplicas cuja soma dos pesos seja maior ou igual a
Qw. Será obtida a réplica com o maior número de versão e todos os nós escolhidos
terão a sua réplica actualizada e um novo número de versão.
Os quorums que permitem operações de leitura e escrita devem ter pelo menos
um nó em comum (que contenha a réplica) e esse nó não deve deixar que sejam feitos
acessos concorrentes conflituosos. Isto assegura que as operações de leitura retornam
o valor atribuído pela última operação de escrita, e que qualquer operação de escrita
concorrente com as operações de leitura estão bem sincronizadas. Os quorums que
permitem operações de escrita devem ter um membro comum, para assegurar que as
operações de escrita não são executadas concorrentemente.
Figura 7 : Método consensual de quorum
27
Bases de Dados Distribuídas
2.4.2 Fragmentação de Dados
A fragmentação é a técnica de dividir logicamente as relações. As tabelas não
são uma unidade lógica apropriada para estruturar uma BDD, já que, normalmente, as
aplicações e seus utilizadores não estão interessados em todos os dados que estas
contêm.
Existem dois tipos de fragmentação:
?
Horizontal – é feita uma selecção à tabela, de acordo com alguma condição
específica;
?
Vertical – é feita uma projecção da tabela.
Também é possível combinar estes dois tipos, originando uma fragmentação
mista.
Tomando o exemplo anteriormente referido da empresa de construção civil, a
fragmentação mais útil para o mestre de obras de Lisboa teria como base,
provavelmente, uma fragmentação baseada na localização do empregado:
CODIGO
NOME
LOCALIZACAO
CARGO
OBRA
2
J. Barros
2
4
2
5
M. Pereira
2
1
1
Tabela 5 : Fraccionamento Horizontal da Tabela de Empregados
Já para o funcionário administrativo que tem a seu cargo o processamento dos
salários, apesar de fisicamente estar no Porto, apenas quer ver esta informação:
CODIGO
NOME
CARGO
1
F. Rodrigues
4
2
J. Barros
4
3
A. Silva
3
4
J. Sousa
2
5
M. Pereira
1
Tabela 6 : Fraccionamento Vertical da Tabela de Empregados
28
Bases de Dados Distribuídas
Para o gestor de projecto que se encontra em Coimbra saber quem são os
empregados da sua área, independentemente do seu cargo e do seu salário:
CODIGO
3
NOME
LOCALIZACAO
A. Silva
3
Tabela 7 : Fraccionamento Misto da Tabela de Empregados
A fragmentação horizontal, por sua vez, divide-se em duas:
? Fragmentação Horizontal Primária;
? Fragmentação Horizontal Derivada.
A fragmentação horizontal diz-se primária quando é definida por uma
condição aplicada directamente à relação, como se pode ver no primeiro exemplo de
fragmentação apresentado.
A fragmentação horizontal é derivada quando é definida por uma condição
que é aplicada aos tuplos de relação diferente. Para exemplificar este caso, pode
apresentar-se a selecção dos códigos e nomes das obras onde trabalham os
empregados com código entre 1 e 3.
CODIGO
NOME
1
Lote 2
2
Loja 34
Tabela 8 : Fragmentação derivada da tabela OBRA
Para que a fragmentação seja correcta, deve ser:
-
Completa – se existe um determinado dado na relação original, existe um
mapeamento que indica onde esse fragmento se encontra, e esse fragmento
existe garantidamente;
-
Reconstruível – a relação original pode ser correctamente reconstruída a
partir dos seus fragmentos;
-
Única – os dados de um fragmento não devem aparecer em mais nenhum,
excepto a chave primária na fragmentação vertical.
29
Bases de Dados Distribuídas
Esta técnica permite o processamento paralelo de uma relação (maior
desempenho) e permite colocar os dados onde são acedidos mais insistentemente
(diminuindo o peso das comunicações).
Os factores que a afectam dividem-se em:
? Estrutura da BD (esquema conceptual global) – temos de saber as ligações
entre os tuplos (chaves estrangeiras / integridade referencial) usadas para
definir fragmentos horizontais derivados;
? Características das aplicações – condições usadas, localização e
frequências de acessos;
? Características da rede – número e localização dos nós, tipo e largura de
banda da rede;
? Capacidade de processamento dos nós.
2.4.2.1 F ragme ntaç ão ho rizo nta l
A primeira coisa a fazer é seleccionar os mintermos e determinar as
frequências de acesso. Mintermos são condições (ou predicados) compostas por
condições simples, que definem conjuntos de dados acedidos como uma unidade por
aplicações / inquéritos, ou seja, candidatos a serem fragmentos horizontais.
Depois de obtidos os mintermos, é importante saber, em média, quantos tuplos
seriam seleccionados por cada e qual a frequência com que esses tuplos seriam
acedidos. Os que seleccionam mais tuplos ou tuplos com maiores frequências de
acesso, seriam preferencialmente escolhidos para base da fragmentação.
Quando nos deparamos com fragmentação horizontal derivada (FHD), o
problema torna-se mais complexo. Quando temos duas ou mais hipóteses de FHD,
devemos escolher aquela que :
-
é acedida mais frequentemente (a não ser nos casos em que os custos de
utilização das aplicações menos acedidas são tão que anulam a diferença
do uso);
-
oferece melhor performance nas operações de join, porque o join é a mais
“cara” das operações algébricas, compensando o esforço de a melhorar.
30
Bases de Dados Distribuídas
Os joins menos pesados computacionalmente são aqueles cujas relações ou
fragmentos a juntar são pequenos, ou aqueles que podem ser processados de um modo
distribuído. Por exemplo, processar o join do fragmento A1 com B1, enquanto o join
do fragmento A2 com B2 é feito separadamente e em paralelo sem ser preciso fazer o
join de A1 com B2 nem o de A2 com B1, porque se sabe que estes nunca produziriam
tuplos.
Para verificar se o join de dois fragmentos poderá (possivelmente) produzir
tuplos, foram criados os Gráficos de Join (Join Graphs).
Figura 8 : Gráfico de Join particionado
De realçar que estes gráficos não indicam se irão existir tuplos tendo em conta
o conteúdo da BD num determinado momento, mas se as definições dos fragmentos
permitem a existência de tuplos ao ser feito o join.
O Phorizontal é um algoritmo que ajuda à tarefa da fragmentação. Tem como
input uma relação R e um conjunto de predicados simples Pr e devolve um conjunto
de predicados mintermos M, de acordo com os quais a relação deve ser fragmentada.
Os seus passos são os seguintes:
1. Pr’ <- COM_MIN(R, Pr);
2. Determinar o conjunto de predicados mintermos;
3. Determinar as implicações entre cada Pi e Pr;
4. Eliminar os mintermos contraditórios de M.
31
Bases de Dados Distribuídas
O COM_MIN é um algoritmo baseado no conceito do minimalismo
(minimality) dos predicados. Um conjunto de predicados diz-se mínimo se todos os
predicados que o compõem são relevantes para a fragmentação (relevantes no sentido
em que fazem com que o fragmento seja ainda mais dividido). Tem como input uma
relação R e um conjunto de predicados simples Pr e retorna um conjunto de
predicados simples, completos e mínimos Pr’ baseado em Pr.
2.4.2.2 F ragme ntaç ão ve rt ic al
Para este tipo de fragmentação também se devem tentar encontrar os
conjuntos de dados que são acedidos como uma unidade. Existem duas técnicas para a
realizar:
? separar as relações originais;
? agrupar os atributos individuais desde o início.
A primeira técnica é mais utilizada, porque facilita a garantia de integridade.
A informação necessária para a fragmentação vertical é:
? As aplicações / inquéritos usam que atributos?
? A frequência com que cada aplicação / inquérito é executada.
A primeira pode ser obtida através da matriz de utilização dos atributos e a
segunda, através da matriz de afinidades entre atributos. Basicamente, o que se quer
fazer é identificar que atributos são acedidos conjuntamente e com que frequência,
para depois fazer o design da fragmentação vertical (de modo a suportar as
combinações mais comuns de atributos, que são usados mais frequentemente).
Claro que, no final, nem todas as aplicações irão ser idealmente suportadas: o
resultado será uma solução de compromisso entre necessidades conflituosas.
A matriz de utilização de atributos tem os atributos num dos eixos e os
inquéritos no outro. Quando um inquérito acede a um determinado atributo, coloca-se
1 na posição correspondente e 0, caso contrário.
32
Bases de Dados Distribuídas
Ex:
Q1 : SELECT nome, cargo FROM EMPREG
Q2 : SELECT nome, proj FROM EMPREG
Q1
Q2
Lisboa
1
5
Porto
10
17
Coimbra
3
0
Tabela 9: Nº de inquéritos efectuados por nó
Inquéritos
Q1
Q2
nome
1
1
Cargo
1
0
Proj
0
1
Atributos
Tabela 10: Matriz de utilização de atributos
A matriz de afinidades entre atributos (MAA) tem os atributos das relações
nos dois eixos. Para a construir determina-se a frequência de acessos (em todos os
nós) para cada inquérito. Depois calcula-se o número de vezes que cada par de
atributos é acedido. De seguida, encontram-se os atributos com valores semelhantes,
de modo a agrupá- los no mesmo fragmento vertical: cria-se uma MAA clustered. Já
existem algoritmos para a realização desta tarefa. Um deles é o Algoritmo de União
de Energias (Bond Energy Algorithm), cujo objectivo é agrupar os valores das
colunas. Segundo este algoritmo, a inicialização é feita fixando uma das colunas. Em
cada iteração serão colocadas as restantes colunas. Para cada uma das colunas, será
escolhida a localização que maximiza a medida de afinidade global (valores elevados
junto com valores elevados, valores inferiores junto com valores inferiores). O passo
final será decidir que atributos são mantidos juntos. Isto poderá ser visto através da
MAA clustered, mas se esta for demasiado complicada, utilizam-se algoritmos de
particionamento.
Atributos
Nome
cargo
Projecto
nome
36
14
22
cargo
14
14
0
projecto
22
0
22
Tabela 11: Inicialização da matriz de afinidades entre atributos
33
Bases de Dados Distribuídas
2.4.2.3 F ragme ntaç ão híbrida
A natureza das aplicações pode exigir uma fragmentação mais complexa. As
técnicas são basicamente as mesmas já apresentadas.
2.4.3. Alocação
Depois de fragmentar as relações, deve estudar-se a sua alocação (colocar o
fragmento num único nó) e/ou replicação (colocar o fragmento em dois ou mais nós).
O objectivo fundamental da alocação é minimizar os custos, ou então optimizar
medidas de performance (tais como tempos de resposta e capacidade de
processamento). Os custos podem incluir:
? custos da comunicação entre nós;
? custos de processamento;
? custos de obtenção e actualização dos dados;
? custos de armazenamento dos dados.
A introdução da primeira cópia é altamente vantajosa porque aumenta a
confiabilidade e disponibilidade do sistema. Mas, a partir daí, o benefício de criar
mais cópias diminui de um modo não linear. Também se devem ter em conta
restrições tais como a capacidade de armazenamento e de processamento dos nós.
A alocação, por envolver um elevado número de variáveis, pode tornar-se um
problema extremamente complexo, e a sua complexidade é directamente proporcional
ao número de nós e de aplicações existentes no sistema. Pode acontecer até que não
seja possível encontrar a solução óptima em tempo útil e, se for esse o caso, ter-se-á
de recorrer a:
? Heurísticas – quando se deseja optimizar o desempenho;
? Programação de fórmulas lineares / inteiras – quando o objectivo é
minimizar os custos;
? Método “melhor medida” (best-fit), para determinar uma alocação sem
replicação. É associada uma medida a cada alocação possível e o nó com a
melhor medida é seleccionado. Para alocar réplicas utiliza-se a variante
“todos os nós beneficiários” (replicar em todos os nós onde o benefício de
34
Bases de Dados Distribuídas
alocar uma cópia é maior que o custo) ou a variante “replicação adicional”
(começar com a solução não replicada e ir progressivamente introduzindo
cópias até que deixe de ser vantajoso).
2.5 Gestão distribuída de transacções
Segundo M.Tamer Özsu e Patrick Valduriez, uma transacção é uma colecção
de acções que faze m transformações consistentes aos estados do sistema, ao mesmo
tempo que preservam a sua consistência.
Nas BDD, as transacções viram a sua complexidade aumentada, já que uma
transacção pode envolver a cooperação de vários nós. Quando isso acontece, a
transacção é chamada “global”, e é dividida em sub-transacções, tantas quantas os nós
envolvidos.
Figura 9 : Execução de uma transacção distribuída 11
11
M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -
www.csse.monash.edu.au/courseware/cse5200
35
Bases de Dados Distribuídas
Apesar destas contingências, as transacções devem manter as suas
propriedades fundamentais:
? Atomicidade – todas as sub-transacções são realizadas (COMMIT) e logo,
também é feito o COMMIT da transacção global, ou todas são abortadas
(ABORT);
? Consistência – cada transacção a executar sozinha numa BD consistente
mantém- na consistente. Ou seja, não devem ser violadas as restrições de
integridade da BD;
? Isolamento – para que esta característica seja uma realidade, é necessário :
o Seriazibilidade;
o Uma transacção incompleta não deve mostrar os seus
resultados às outras transacções antes de ser feito o seu
COMMIT (evitando aborts em cascata).
Ao existir isolamento evitam-se vários problemas :
o Leitura suja (dirty read) – a transacção T1 modifica o item de
dados X, que é, de seguida, lido por T2 antes de T1 terminar;
T1 aborta; T2 leu um valor que nunca existiu na BD;
o Leitura não repetível ou confusa (fuzzy read) – T1 lê X; t2
modifica ou apaga X e faz COMMIT; T1 tenta ler X outra vez,
mas lê um valor diferente ou não o consegue encontrar;
o Fantasmas (phantom) – T1 procura na BD tuplos de acordo
com um predicado enquanto T2 insere novos tuplos que
satisfazem esse predicado.
? Persistência – a partir do momento em que é feito o COMMIT, o sistema
deve garantir que os resultados não desaparecem, mesmo que existam
falhas subsequentes.
36
Bases de Dados Distribuídas
2.5.1 Protocolos de segurança
Para que as características fundamentais das transacções (mais conhecidas por
ACID: Atomicity, Consistency, Isolation, Durability) pudessem ser uma realidade nas
BDD, foi necessário criar protocolos de segurança:
? protocolos de COMMIT;
? protocolos de ABORT ou terminação;
? protocolos de recuperação.
Cada nó tem um gestor de transacções local, responsável por manter o log
(para recuperação caso seja necessário) e por participar na coordenação da execução
concorrente de transacções a executar no próprio nó. Também tem um coordenador de
transacções, responsável por iniciar a execução de transacções que começam nesse
nó, por distribuir as sub-transacções pelos nós apropriados, e por coordenar a
terminação de todas as transacções que começam no próprio nó (fazer o COMMIT ou
o ABORT em todos os nós).
2.5.1.1 P rotoc olos de C O MMIT
Asseguram que a propriedade da atomicidade da transacção é respeitada. O
protocolo mais conhecido e mais simples é o Two-Phase Commit (COMMIT em duas
fases) ou 2PC.
Figura 10 : Protocolo 2PC12
12
M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -
www.csse.monash.edu.au/courseware/cse5200
37
Bases de Dados Distribuídas
O nó coordenador (controla o protocolo) envia uma mensagem “Pronto para
COMMIT?” (1) a cada um dos nós participantes envolvidos na transacção em causa.
Estes respondem com uma mensagem de “Pronto”, indicando que está preparado para
fazer o COMMIT da sua parte da transacção, ou então com uma mensagem de
“Abort ”, indicando que não é possível fazer o COMMIT (2). Todos os participantes
têm de responder com “Pronto” para que o COMMIT da transacção possa ocorrer.
Senão, é enviado um “Global Abort ” a todos os participantes para que abortem as
suas sub-transacções. Ou seja, basta um “Abort ” de um dos nós para que toda a
transacção falhe.
Existem três implementações do 2PC:
? centralizada – todas as comunicações envolvem o nó coordenador;
? linear – os nós comunicam numa sequência ordenada, a partir do
coordenador;
? distribuída – todos os nós comunicam uns com os outros directamente.
O 2PC pode bloquear devido à falha de um dos nós durante o processo. Uma
transacção bloqueada não é desejável porque continua a manter os locks dos recursos
de que necessita para a sua transacção – impedindo que outras transacções que
precisem desses mesmos recursos os possam obter.
Para ultrapassar esta limitação do 2PC, foi criado o Three-Phase Commit (3PC).
Este é semelhante ao 2PC, mas com um passo adicional intermédio (Pre-Commit),
que confirma que todos os nós estão em condições de finalizar. Na prática, porém,
como este protocolo aumenta ainda mais o tráfego de mensagens, não teve aceitação
comercial.
2.5.1.2 P rotoc olos de AB O R T o u Te rminaç ão
Se uma falha ocorrer, estes protocolos indicam aos restantes nós como lidar com
o facto. Tipicamente, os outros nós não devem ter de esperar até que a falha seja
reparada para terminar a transacção.
No caso do 2PC, se um nó participante falha, por exemplo:
-
se o coordenador se encontra no estado WAIT, é necessário abortar a
transacção;
38
Bases de Dados Distribuídas
-
se o coordenador se encontra no estado COMMIT ou ABORT, deve
reenviar a mensagem de COMMIT / ABORT global ao nó em falha.
2.5.1.3 P rotoc olos de Re c upe raç ão
Depois de os nós que falharam voltarem a ficar operacionais, estes protocolos
indicam- lhes as medidas que devem tomar para se sincronizarem com os restantes
nós. Voltando ao caso do 2PC:
-
se o coordenador falha no estado WAIT, quando em recuperação, pode
simplesmente recomeçar o processo de COMMIT;
-
se o participante falha no estado READY, quando em recuperação, pode
perguntar ao coordenador o que fazer quanto à sub-transacção
interrompida.
2.5.2 Controlo de Concorrência
Existem várias técnicas para sincronizar transacções concorrentes de modo a
manter a consistência da BD, enquanto ao mesmo tempo é atingido o máximo grau de
concorrência.
O escalonamento (ou história) de execução é a ordem por que as operações de
um conjunto de transacções é executada. Um escalonamento serial é aquele onde as
transacções ocorrem consecutivamente. Se cada transacção for consistente (obedecer
às regras de integridade), é garantida a consistência da BD no fim da execução de
todas as transacções. Num escalonamento serializável, as transacções executam
concorrentemente, mas o efeito prático sobre a BD é equivalente ao de um
escalonamento serial. Equivalente em que aspectos?
-
equivalência de conflitos : a ordem relativa de execução de operações
conflituosas pertencentes a transacções que não foram abortadas em dois
escalonamentos é a mesma;
-
operações conflituosas: duas operações (por exemplo, Read e Write)
entram em conflito se acedem ao mesmo item. Na prática, não se pode
39
Bases de Dados Distribuídas
mudar a sua ordem relativa de execução. Se duas operações de duas
transacções diferentes entrarem em conflito, as transacções dizem-se
conflituosas.
Os algoritmos de controlo de concorrência dividem-se em pessimistas (dos
quais se pode dar como exemplo o Two-Phase Locking ou 2PL, algoritmos de
timestamp e híbridos) e optimistas.
O algoritmo Two-Phase Locking tem duas fases: a de obtenção de locks e a de
libertação de locks. Cada transacção deve obter os locks de todos os objectos de que
vai necessitar antes de os usar. Se um objecto já estiver locked por uma outra
transacção, todas as outras têm de esperar. Quando a transacção liberta um dos locks,
não pode pedir outros.
No 2PL distribuído, dois escalonamentos 2PL são colocados em cada nó para
gerir os locks dos objectos desse nó. Uma transacção pode ler qualquer uma das
réplicas de um objecto: basta- lhe para isso pedir o lock a qualquer um dos nós do
sistema onde exista essa réplica. Escrever num objecto já implica obter os locks de
escrita de todos os objectos.
Figura 11 : Fases do Two-Phase Locking 13
13
M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -
www.csse.monash.edu.au/courseware/cse5200
40
Bases de Dados Distribuídas
No algoritmo de timestamp, a abordagem é diferente: a cada transacção é
atribuído um timestamp único em todo o sistema. A cada item de dados é atribuído
um read timestamp e um write timestamp. Operações conflituosas são resolvidas
usando o ordenamento timestamp.
O modo como são gerados os timestamps deve ser objecto de algum cuidado
para que estes sejam, de facto, únicos. Segundo o método de Lamport, o timestamp é
um número caracterizado por dois grupos de dígitos: os menos significativos
identificam o nó onde ocorreu o evento, enquanto os mais significativos indicam os
eventos que ocorreram nesse nó. Estes últimos podem ser obtidos quer através de um
contador lógico quer através de um relógio local. De cada vez que dois nós trocam
uma mensagem, os timestamps são sincronizados. O receptor deve ter um timestamp
maior do que o do emissor, e se isso não for verdade, a transacção é abortada. O
contador local do receptor é avançado, e é feita uma nova tentativa.
Nos algoritmos de locking e nos de timestamp que implicam espera podem
ocorrer deadlocks. Existem várias estratégias alternativas para lidar com este
problema:
-
Ignorar: deixar o programador lidar com o problema ou fazer restart do
sistema;
-
Prevenir: garantir que os deadlocks não chegam sequer a ocorrer.
Verificar a transacção quando esta inicia e pré-declarar todos os recursos
de que vai necessitar. Este método tem a desvantagem de reduzir a
concorrência (devido à pré-alocação) e aumentar o overhead (por ter de
determinar se a alocação é segura). Por outro lado, temos a garantia de
não existirem rollbacks ou restarts;
-
Evitar: detectar potenciais deadlocks antes de estes ocorrerem e tomar
medidas para que isso não aconteça. As transacções podem avançar, a não
ser que algum recurso esteja indisponível; neste caso podem esperar por
um determinado período de tempo. É mais vantajoso que o método
anterior;
-
Detectar e recuperar: se os deadlocks ocorrerem, detectá- los e obrigá- los
a terminar.
41
Bases de Dados Distribuídas
Para a detecção pode recorrer-se a Gráficos de Espera (Wait-For Graphs WFG). Estes podem ser transmitidos a um único nó responsável pela tarefa de
detecção (detecção centralizada), a um nó pai (detecção hierárquica) ou a outros nós
(detecção distribuída). Nesta última estratégia, todos os nós cooperam para a detecção
de deadlocks. Cada nó cria um WFG e resolve os deadlocks locais, caso existam. Se
existirem potenciais deadlocks globais, o nó envia o WFG para o nó seguinte ou para
o nó anterior.
A frequência de transmissões deve ser adequada às capacidades da rede de
comunicações e às implicações da ocorrência de um deadlock sobre as aplicações e
dados envolvidos. Demasiadas transmissões implicam um maior custo das
comunicações, mas têm como vantagem menores atrasos devido a deadlocks não
detectados. Poucas transmissões, por outro lado, provocam maiores atrasos caso
ocorra um deadlock, mas os custos de comunicação são menores.
2.6 Processamento distribuído de questões
O processamento distribuído de questões é o processo de obter dados de
diferentes nós. Várias estratégias podem, então, ser congeminadas. Nos sistemas
centralizados, o primeiro critério para medir o custo de uma determinada estratégia
era o número de acessos a disco. Num sistema distribuído, outros critérios devem ser
levados em conta, incluindo o custo da transmissão de dados sobre a rede e a
possibilidade de paralelismo.
A função de obtenção de dados tem três componentes:
Custo de I/O + custo de CPU + custo de comunicações
Dependendo do ambiente distribuído (LAN ou WAN), deve prestar-se mais
atenção a um ou outro custo. Nas WANs, os custos de transmissão são dominantes (é
possível, mesmo, ignorar os outros factores), enquanto nas LANs deve-se ter em
conta a função global. Nas LANs já é possível recorrer aos broadcasts.
42
Bases de Dados Distribuídas
A optimização de questões começa, inclusive, na fragmentação e alocação
desses mesmos fragmentos. De facto, se a alocação for bem estruturada, os custos
podem ser minimizados e o desempenho do sistema optimizado.
O processamento distribuído de questões enfrenta várias questões complexas,
a começar logo no cálculo do custo do modelo. Devem, aliás, utilizar-se heurísticas
para reduzir o número de alternativas de optimização dos inquéritos. É necessário
encontrar uma solução de compromisso entre a necessidade de optimização e a
necessidade de reduzir os custos de execução. Por vezes, a optimização tem um tempo
de vida limitado devido a mudanças no sistema, o que implica reoptimizações dos
inquéritos (que reflictam a nova realidade). Num sistema em constante mutação, é
contraproducente consumir muitos recursos e tempo de execução para encontrar o
melhor escalonamento: eventualmente será necessário reflectir essas mudanças, e
encontrar um novo escalonamento.
Depois de encontrado o melhor escalonamento global, é necessário proceder a
optimizações locais, seleccionando o melhor caminho de acesso e utilizando técnicas
de optimização centralizadas.
A necessidade de manter a integridade dos dados do sistema não é
problemática nos sistemas homogéneos. Mas, nos heterogéneos, onde as restrições de
integridade são, muitas das vezes, diferentes, obrigam a que seja necessário resolver
conflitos de resolução antes de se poder avançar para o inquérito global. Estes
conflitos existem a três níveis:
? inconsistências em restrições de integridade locais;
? dificuldades em especificar restrições de integridade globais;
? inconsistências entre restrições de integridade locais e globais.
As restrições de integridade globais, apesar de difíceis de implementar, podem
eliminar as inconsistências locais em cada BD individual. As restrições de integridade
globais, por outro lado, não estão ligadas às BDs individuais e pode não ser prático
mudar a organização da estrutura para tornar a BD consistente. Nestes casos, as
inconsistências entre restrições de integridade locais e globais são inevitáveis. A
43
Bases de Dados Distribuídas
resolução dos conflitos depende do nível de controlo centralizado. Se este controlo for
forte, as restrições de integridade globais terão precedência. Caso contrário, serão as
locais.
2.6.1 Passos do processa mento distribuído de questões
Os passos no processamento distribuído de questões são explicitados de
seguida:
? Decomposição;
? Localização;
? Optimização do inquérito global.
A utilização de árvores de análise algébrica facilita o trabalho da verificação
do processamento distribuído de questões ao apresentar de um modo gráfico os passos
da questão. Os inquéritos remotos são imediatamente localizados, permitindo mais
rapidamente remeter para o servidor adequado a execução do sub- inquérito.
2.6.1.1 De c ompos iç ão
Compõe-se de três fases:
1. Normalização
Transformação de SQL em álgebra relacional e verificação léxica e
sintáctica (validade, atributos e relações, tipos).
Ex:
SELECT OBRA.nome
FROM OBRA O, LOCALIZACAO L
WHERE O.orcamento > 30.000.00
AND O.localizacao = L.codigo
AND L.localizacao = “Porto”
44
Bases de Dados Distribuídas
? nome
? O.orcamento > 30.000.00
? O.localizacao = L.codigo
OBRA
? localizacao = “Porto”
LOCALIZACAO
Figura 12 : Árvore de análise algébrica
2. Análise e simplificação
Neste passo, eliminam-se as redundâncias:
Ex.
O.orcamento > 30.000.00 AND O.orcamento > 45.000.00
Passa a ser apenas : O.orcamento > 45.000.00
Verificam-se disjunções e negações. No exemplo seguinte é necessário
alertar o utilizador da impossibilidade de tuplos resultado.
Ex.
O.orcamento > 30.000.00 AND O.orcamento < 20.000.00
3. Reestruturação
De modo a minimizar a quantidade de dados a transmitir, tenta-se “puxar” o
SELECTS para baixo, na árvore.
45
Bases de Dados Distribuídas
?
nome
? O.localizacao = L.codigo
?
O.orcamento > 30.000.00
OBRA
?
localizacao = “Porto”
LOCALIZACAO
Figura 13 : Árvore de análise algébrica reestruturada
Para ajudar à reestruturação devem ter-se presentes as regras de transformação
algébrica (em Anexo).
2.6.1.2 Loc alizaç ão
O objectivo desta fase é determinar que fragmentos estão envolvidos e, para
cada query global, substituir o seu programa específico e optimizar.
Junto com as regras de transformação devem usar-se as regras de redução. A
ideia é substituir as tabelas por uniões de fragmentos e então aplicar as regras de
transformação já mencionadas. Ao usar uma representação em árvore, pode ver-se
que operações podem ser feitas localmente e quais devem ser transferidas para outro
nó. Operações locais correspondem a sub-árvores onde as folhas são fragmentos
locais.
1ª regra de redução
A selecção de fragmentos com uma condição contradizendo a condição da
regra de fragmentação é vazia.
Ex.:
Divide-se OBRA em
O1 (orcamento ? 50.000.00)
O2 (orcamento > 50.000.00)
46
Bases de Dados Distribuídas
O inquérito a considerar:
SELECT nome FROM OBRA
WHERE orcamento > 70.000.00
? nome
? nome
? orcamento
? nome
?
? orcamento
=
=
?
? orcamento ? orcamento
O1
O2
O2
O1
O2
Figura 14 : Optimização de um inquérito seguindo a primeira regra de redução.
Construiu-se uma árvore de inquéritos global, traduziu-se a árvore global para
uma árvore de inquéritos fragmentada e rearranjou-se esta última, puxando as
selecções para as folhas da árvore. Finalmente, reduziu-se a árvore, eliminando as
sub-árvores onde as condições contradizem o critério de distribuição.
2ª regra de redução
Os joins podem ser simplificados, quando as relações sobre as quais vai ser
feito o join são fragmentadas de acordo com o atributo do join. Alguns deles
podem ser eliminados caso não existam linhas no join (determinadas pelos
predicados da fragmentação).
Ex. : Divide-se EMPREG e OBRA da seguinte maneira:
EMPREG1 : ? cargo=1,2
EMPREG2 : ? cargo=3,4
OBRA1 : OBRA ? local EMPREG1
OBRA2 : OBRA ? local EMPREG2
47
Bases de Dados Distribuídas
Inquérito a considerar:
SELECT * FROM EMPREG, OBRA
WHERE EMPREG.obra = OBRA.codigo
AND EMPREG.cargo=1
?
?
? local
local
OBRA1
? cargo=1,2
OBRA2
? cargo=3,4
EMPREG1
EMPREG2
Figura 15 : Árvore de análise algébrica
Para este inquérito pode facilmente deduzir-se que a sub-árvore direita pode
desaparecer, o que poupa tempo de computação e custo de comunicação do segundo
join.
2.6.1.2 O pt imizaç ão do inqué rito g loba l
Nesta fase, tenta-se encontrar um bom (não necessariamente óptimo)
escalonamento global. Para isso, existem diversas estratégias:
? Minimizar a função custo;
? Processamento distribuído de joins;
? Utilização de semi-joins – poupa-se no custo de comunicação à custa de
maior processamento local;
? Diferentes métodos de join – nested loop vs. joins ordenados (merge join
ou hash join).
48
Bases de Dados Distribuídas
É importante que o sistema mantenha alguns valores de controlo tais como:
? Custo de planos – estimativa do custo de processamento da operação
somado ao tamanho do resultado;
? Estatísticas – Obter as cardinalidades, tamanho e índice das relações. Esta
é uma função do SGBD;
? Resultados intermédios – Para os casos em que o resultado de uma
operação é o input de outra.
Como os joins são as operações mais “caras”, quer do ponto de vista
computacional, quer do ponto de vista das comunicações, apareceram vários
algoritmos com o objectivo de optimizar o seu escalonamento, entre os quais o
Distributed INGRES, o System R* e o SDD-1. Este último é orientado não ao
ordenamento dos joins, mas ao dos semi-joins 14 .
Para se ter uma ideia mais clara das características destes três algoritmos,
atente-se na tabela abaixo:
Algorit.
Função
Factores a optimizar
objectivo
Estatís- Fragmentação
joins
Tempo de respos- Tamanho das mensagens,
Dist.
Semi-
ta ou tempo total
custo do processamento
Tempo total
Nº e tamanho das
ticas
Não
1
Horizontal
Não
1,2
Não
Sim
1,3,4,5
Não
INGRE
S
R*
mensagens, IO, CPU
Tempo total
SDD-1
Tamanho das mensagens
Tabela 12 : Algoritmos de optimização de inquéritos distribuídos
Leg. : 1: cardinalidade da relação; 2: número de valores únicos por atributo; 3: factor de
selectividade do join; 4: tamanho da projecção em cada atributo do join; 5: tamanho do
atributo e do tuplo.
14
Um semi-join é vantajoso quando tamanho(?
A
(S)) + tamanho ( R ? A S) < tamanho (R)
49
Bases de Dados Distribuídas
O algoritmo Distributed INGRES :
O Distributed INGRES decompõe cada inquérito com várias variáve is numa
sequência de inquéritos com uma única variável, onde uma das variáveis é comum.
Depois de processar cada inquérito, escolhe um inquérito inicial (recorrendo, se
necessário, a heurísticas), e ordena os restantes recorrendo aos tamanhos das relações
intermédias. É necessário ter em consideração a localização distribuída de fragmentos.
É possível optimizar o resultado em relação ao custo de comunicação ou ao tempo de
resposta.
O algortimo R* :
Na versão centralizada deste algoritmo, os inquéritos (também com uma única
variável) são executados segundo o melhor caminho de acesso. Os joins são
processados, e depois, são determinados todos os ordenamentos possíveis, e é
calculado o custo de cada ordenação. No final, é escolhido o ordenamento com menor
custo.
Na versão distribuída, o custo inclui também a transmissão. É feita um busca
exaustiva da melhor solução (o que, em alguns casos, torna-se impraticável).
Existem duas formas diferentes de processar os joins neste algoritmo:
transferir todos os dados de uma vez só ou transferir os dados à medida que estes são
necessários. Na primeira abordagem, o número de mensagens é menor, mas as
transferências de dados são maiores, o que é conveniente quando as relações são
pequenas. Já a segunda abordagem implica um maior número de mensagens, com
transferências de dados menores, sendo este o caso conveniente se as relações
contiverem muitos tuplos e a selectividade for boa.
O algoritmo SDD-1 :
Este algoritmo utiliza semi-joins se estes forem vantajosos, mas não leva em
conta a possibilidade de as relações estarem fragmentadas nem replicadas. O custo de
transferir o resultado desde o nó onde o resultado final foi calculado para o nó que fez
50
Bases de Dados Distribuídas
o pedido não é considerado. É baseado no algoritmo Hill Climbing 15 , cuja estratégia é
determinar a melhor solução inicial e, iterativamente, tentar melhorá- la. A
desvantagem deste algoritmo é posta a descoberto quando existem mínimos locais: se
o escalonamento óptimo tiver um custo inicial alto, este algoritmo não o irá encontrar
porque não o terá escolhido como solução inicial.
2.7 Bases de Dados Distribuídas Móveis
Com os avanços nos sistemas móveis (portáteis, telemóveis...) começou a ser
possível a existência de bases de dados em que alguns nós não são fixos. Esta
possibilidade é bastante útil no mundo empresarial, e muito particularmente no caso
das empresas seguradoras com pequenos mediadores espalhados geograficamente,
cuja ferramenta de trabalho é apenas um portátil.
Os sistemas de computação móveis podem ser vistos como uma classe
especializada de sistemas distribuídos, onde alguns nós podem libertar-se de
operações distribuídas conjuntas, mover-se sem restrições no espaço físico e, mais
tarde, reconectarem-se a um segmento de uma rede de computadores, talvez diferente,
de modo a retomar as actividades suspensas.
Estes sistemas, para além da complexidade introduzida pela distribuição dos
dados, têm de se confrontar com as dificuldades inerentes à mobilidade:
? Os elementos móveis são pobres em termos de recursos, relativamente aos
elementos estáticos – o seu peso, tamanho, energia despendida e
características ergonómicas jogam contra a performance obtida;
? Os elementos móveis estão mais sujeitos a danos – é facilmente
constatável que um portátil tem maiores probabilidades de cair, estragar-se
devido a causas naturais (chuva, calor, etc.) ou ser roubado;
? A conectividade é muito variável em performance e confiabilidade – um
computador tem de contentar-se com uma rede sem fios, com baixa largura
de banda e possíveis falhas na cobertura (túneis, por exemplo);
15
Subida da montanha, numa tradução literal.
51
Bases de Dados Distribuídas
? Os elementos móveis dependem de fontes de energia limitada – apesar de
as baterias terem melhorado ao longo do tempo, os elementos devem
poupar o máximo de energia possível, num esforço quer ao nível do
hardware, quer do software.
Uma das características mais importantes que estes sistemas devem ter é a da
adaptividade, de modo a que possam responder com rapidez e eficiência às mudanças
a que estão sujeitos. As estratégias de adaptação variam entre o tipo laissez faire, onde
a adaptação é da inteira responsabilidade das aplicações, e o tipo applicationtransparent, onde esta responsabilidade passa a estar do lado do sistema. Como
sempre, a melhor solução reside algures no meio, na chamada adaptação applicationaware, onde existe uma colaboração entre as aplicações e o sistema. Assim, as
aplicações determinam a melhor forma de se adaptarem tendo em conta as suas
necessidades e características (algo que falhava na segunda abordagem, já que o
sistema não tem esses conhecimentos), enquanto o sistema monitoriza os recursos e
decide quais as alocações a realizar (o que faltava na primeira estratégia).
A agilidade é a medida da capacidade de o sistema responder prontamente a
perturbações como a diminuição da largura de banda ou da energia disponível. Um
sistema deve ser ágil, mas não em demasia, sob pena de se tornar instável,
consumindo todos os recursos ao reagir à mínima perturbação e, por isso, realizando
pouco processamento útil.
Quando se fala em sistemas móveis, fala-se no conceito de célula. A área
geográfica do sistema está dividida em células, cada uma das quais servida por uma
estação base (base station). Cada estação base está ligada à rede fixa e fornece uma
ligação sem fios entre o utilizador móvel e o resto da rede. Adicionalmente, pode
existir uma hierarquia de servidores de localizações, ligados entre si e às estações
base, por uma rede normal. Os servidores de localizações são, como o seu nome
indica, responsáveis por manterem as localizações dos utilizadores, quer sob a forma
de célula, quer sob uma forma aproximada: uma zona, ou uma partição de células.
52
Bases de Dados Distribuídas
Figura 16 : Exemplo do tipo de células existentes numa rede móvel16
Utilizando esta última abordagem, evitam-se constantes actualizações da
localização, que se pode tornar demasiado exigente em termos de recursos. Já não é
necessário saber a localização exacta do utilizador, mas apenas a célula onde ele se
encontra. No entanto, esta ignorância acerca da localização exacta deve ser limitada,
isto é, não deve estar muito longe da verdade. Quando se pretende localizar um
utilizador procuramos a sua célula. Mas, esta pode variar ao longo do dia, da semana e
até do mês. De facto, uma pessoa passa algumas horas do dia em casa, outras no
emprego, ao fim de semana pode variar um pouco o percurso... Ao criar um perfil de
utilizador, esta tarefa pode ser facilitada: monitorizando a actividade do utilizador
(número de chamadas, deslocações ao longo do dia e da semana... ) obtém-se uma
série de localizações prováveis ao longo do tempo. Quando é necessário localizar um
utilizador começa-se por procurar nos locais indicados pelo perfil.
Os algoritmos de localização de utilizadores mais utilizados variam entre:
1. Broadcast – é iniciado dentro da partição. O custo é dependente do
número de estações base dentro da partição;
16
http://www.csse.monash.edu.au/courseware/cse5501
53
Bases de Dados Distribuídas
2. Serviços centrais – é mantida uma base de dados das localizações actuais,
centralizada logicamente;
3. Home bases – cada computador móvel tem o seu servidor centralizado.
Pode criar problemas de disponibilidade;
4. Apontadores – de cada vez que existe uma deslocação, é criado um
apontador para a nova localização na antiga localização.
O modelo cliente / servidor foi ligeiramente modificado nos sistemas móveis.
Devido às características intrínsecas destes sistemas, por vezes, a diferença entre
clientes e servidores é esbatida:
? Limitações nos recursos forçam a que algumas actividades dos clientes
tenham de ser migradas para servidores;
? Algumas actividades dos servidores têm de ser migradas para os clientes
devido à baixa largura de banda e a desconexões.
Estas situações são apenas temporárias, em ocasiões em que o desempenho e a
disponibilidade do sistema assim o exigem. Durante a execução normal do sistema, os
servidores continuam a ser a fonte fiável dos dados, enquanto os clientes (em maior
número e mais propensos a falhas) podem aceder a esses mesmos dados.
Baseado também no modelo cliente / servidor, o modelo de agentes móveis
veio substituir a tecnologia RPC. Um agente móvel é um programa de software que se
pode deslocar autonomamente de uma máquina para outra, decidindo que nós visitar e
que instruções processar. Pode até suspender a execução num determinado ponto,
transportar-se para uma outra máquina e continuar a execução, a partir do ponto onde
a tinha interrompido (no caso dos agentes móveis com forte mobilidade). As
diferenças em relação ao RPC residem na forma como os pedidos são tratados: em
vez de serem requisitados, os procedimentos em si são fornecidos, assim como os
dados e o estado.
Os agentes têm grande utilidade no acesso a SGBDs baseados na tecnologia
Web, podendo ser utilizados entre clientes e servidores. O cliente envia um agente ao
servidor remoto. Uma vez no servidor, o agente móvel encarrega-se de iniciar os
drivers necessários (tipicamente JDBC ou Java), liga-se à BD, realiza o inquérito e
54
Bases de Dados Distribuídas
leva os resultados de volta ao cliente. As vantagens deste esquema são óbvias: o
cliente torna-se mais leve e portável, remetendo a responsabilidade da activação dos
drivers para os agentes, melhorando assim o seu desempenho.
Nos sistemas móveis, os agentes beneficiam da sua extrema mobilidade para
de deslocar para diferentes nós devido ao dinamismo do ambiente: recursos
computacionais, capacidade da bateria, memória, largura de banda e desconexões, etc,
etc.
A segurança é outro problema agravado pela mobilidade: é mais fácil
interceptar as comunicações móveis; os próprios portáteis estão mais sujeitos a ser
roubados, e com eles, informações confidenciais.
A encriptação dos dados é uma solução possível, assim como a utilização de
esquemas de autenticação do tipo login/password.
Replicação
Os dados devem ser guardados próximo dos nós onde vão ser requisitados,
para assegurar a sua utilização eficiente e para que os tempos de acesso a estes
mesmos dados sejam reduzidos. Dados cujo número de leituras ultrapasse o de
escritas devem ser replicados, mas quando as actualizações são constantes, a
necessidade de manter os dados consistentes torna-se um sério problema em sistemas
onde a disponibilidade, assim como a largura de banda é baixa.
A replicação, mesmo a dos servidores, deve ser optimista: caso ocorram
conflitos existem mecanismos de reparação baseados em logs, mecanismos
específicos às aplicações, ou até mesmo
mecanismos de detecção que implicam
resolução manual.
As caches dos computadores desempenham um importante papel na
replicação. A utilização da cache pode melhorar bastante o desempenho dos sistemas
(uma boa parte das operações é, normalmente, feita em condições de fraca
conectividade). A estratégia de manutenção de informação nas caches deve ser
cuidadosamente pensada, já que os tempos de resposta nos sistemas móveis têm
prazos extremamente limitados. De modo a que esta técnica seja efectiva foram
criados mecanismos de validação rápida da cache e reintegração da propagação de
actualizações.
55
Bases de Dados Distribuídas
A criação de cópias primárias virtuais pretende aumentar a disponibilidade dos
sistemas. Duas cópias actuam como uma única cópia primária, para que, se uma das
cópias não estiver disponível, as transacções possam continuar. A sincronização é
feita mais tarde, ou quando o elemento móvel se conecte novamente.
No sistema Bayou17 foi implementada uma outra abordagem, a read-any /
write any, que permite que o utilizador possa ler e/ou escrever em qualquer cópia
existente na BD, mesmo quando desconectado. Para impedir que os dados fiquem
inconsistentes, foi adoptado um protocolo anti-entropia que, basicamente, assegura
que todas as cópias da BD irão eventualmente convergir para o mesmo estado, se não
existirem novas actualizações. Periodicamente, cada servidor selecciona outro para
uma troca de actualizações. No final, os dois servidores terão cópias idênticas da base
de dados, isto é, terão as mesmas actualizações e na mesma ordem.
O modelo two-tier é uma outra abordagem para tentar resolver o problema da
replicação nos sistemas móveis. As versões das réplicas podem variar entre master
(valor mais recente obtido de um nó base) e tentativa (valor mais recente devido a
actualizações locais); as transacções podem ser do tipo base (apenas para réplicas
master) e tentativa (apenas para réplicas tentativa). Estas últimas originam novas
versões tentativa e uma transacção base para ser processada mais tarde. Uma
transacção base gerada por uma tentativa pode falhar ou produzir resultados
diferentes. Uma transacção tentativa falha se a transacção base não tiver “critério de
aceitação”. Assim, a BD master está sempre num estado de convergência, e nós
móveis apenas precisam de contactar os nós base para verificar se as suas transacções
são aceitáveis.
Gestão de Transacções
Devido às constantes falhas, os sistemas podem ter de desligar, mesmo que
existam transacções pendentes. O Gestor de Transacções de um destes sistemas deve
ainda ser capaz de distinguir uma simples desconexão momentânea e uma falha. Para
que não seja necessário proceder a constantes rollbacks, foram criadas alternativas:
17
O sistema Bayou é uma plataforma de BDD móveis com elevados níveis de disponibilidade e
consistência, onde é possível construir aplicações colaborativas.
56
Bases de Dados Distribuídas
? Transacções com pontos de controlo (savepoints) – Nos pontos de
controlo, os resultados são guardados para o caso de ocorrer uma falha. Se,
de facto, esta ocorrer, pode recomeçar a partir desse ponto;
? Transacções em cadeia – É uma variante da anterior, mas os savepoints
foram substituídos por pontos de commit. A transacção, em caso de falha,
recomeça a partir desse ponto, mas não pode ser rolled back para além
dele. Os locks podem ser libertos nestes pontos, se não forem mais
necessários, mas os resultados apenas são visíveis no final da transacção
global;
? Transacções aninhadas – Cada transacção é dividida numa hierarquia de
sub-transacções. Cada uma pode fazer commit ou rollback, mas a
transacção pai tem de fazer commit para que os subcommits tenham efeito;
? Transacções multi-nível – Estas combinam as propriedades das
transacções em cadeia e das aninhadas. Uma transacção multi- nível é
equivalente a uma aninhada, mas é permitido antecipar o commit de uma
sub-transacção. Se a transacção pai for rolled back, existem transacções
compensatórias para desfazer semanticamente a sub-transacções originais.
O sistema Coda introduziu o conceito de transacções isolation-only (apenas
isolamento). A ideia é incorporar selectivamente os conceitos de ACID transacções,
fazendo exigências mínimas aos clientes móveis, tipicamente com poucos recursos.
A seriazibilidade pode ser assegurada por métodos de Two-Phase Locking e
timestamp, ou até controlo optimista da concorrência. Se for possível manter o
sistema num estado inconsistente, desde que não afecte as necessidades das
aplicações, deve utilizar-se essa estratégia, porque permite um maior grau de
concorrência e melhor desempenho.
Processamento de Questões
O novo problema levantado pela mobilidade dos sistemas prende-se com o
conhecimento impreciso sobre as localizações dos utilizadores. Como minimizar os
custos de comunicação para “descobrir” a informação em falta para completar o
inquérito? Mesmo depois de descoberta a estratégia com custo mínimo, o trabalho do
processamento de questões não acabou. Num ambiente em constante mudança, os nós
57
Bases de Dados Distribuídas
escolhidos para processar a questão podem falhar, e outros, que anteriormente
estavam desconectados, podem estar novamente operacionais. Os planos de execução
devem ser optimizados regularmente, durante o processamento, permitindo que o
sistema se adapte dinamicamente às flutuações nos recursos, às características dos
dados e às preferências do utilizador. Reoptimizar um plano de execução nestas
condições requer cuidados extra na manutenção dos estados da execução. As alturas
ideais para proceder a esta reoptimização são aquelas em que a execução alcança o
chamado “momento de simetria”, onde os operadores algébricos podem facilmente
ser reordenados. Para uma maximização destes momentos, os joins a utilizar nestes
sistemas seriam preferencialmente os da família Ripple Join. Esta família de
algoritmos é baseada no conceito de pipeline. O processamento do join é feito em
“rectângulos” e, no fim de cada rectângulo, a procura pode ser adaptada às mudanças
que se vão operando no desempenho e/ou nas estatísticas obtidas.
2.8 Recentes avanços na tecnologia das BDD
Os sistemas de BD do modelo relacional estão em uso há bastantes anos e
servem bem os propósitos das aplicações tradicionais com tipos de dados simples,
como são os numéricos e textuais.
Porém, as aplicações têm mudado radicalmente, necessitando de novos tipos e
modelos de dados, sem deixarem de necessitar de alguns dos serviços fornecidos
pelos SGBD, tais como a persistência, confiabilidade e a consistência. As
telecomunicações, a multimédia e os sistemas de informação geográfica são apenas
alguns exemplos de aplicações que precisam de modelos de dados complexos e de
novos tipos de operações (por vezes, até dependentes do tipo de informação), que o
modelo relacional não oferece.
Para ultrapassar estes problemas foram criadas as bases de dados orientadas a
objectos (OODB), as bases de dados objecto-relação (ORBD) e as bases de dados de
3ª geração.
58
Bases de Dados Distribuídas
Bases de Dados Orientadas a Objectos
Uma BDOO é uma colecção de objectos, cada um deles com um OID
(identificador único do objecto), um estado (colecção de valores associados às
propriedades do objecto) e um comportamento (descrito pelos métodos que podem ser
invocados pelo objecto). O uso de tipos e valores complexos permite associar a um
objecto uma estrutura arbitrária, o que no modelo relacional só é possível recorrendo à
utilização de múltiplas relações. Além disso, o valor de uma propriedade de um
objecto pode ser o OID de um outro objecto, implementando assim, uma referência.
Os objectos têm um tipo associado e uma classe (implementação):
? o tipo é uma abstracção que descreve o estado e o comportamento do
objecto;
? a classe descreve a implementação do tipo: estrutura dos dados e
implementação dos métodos, ou seja, a codificação dos métodos numa
linguagem de programação OO.
O SQL não é adequado para trabalhar com este modelo, daí a necessidade de
criação da ODL (Object Definition Language) para a definição dos dados e sua
estrutura, e da OQL (Object Query Language), baseada na SQL3.
Exemplo de OQL:
SELECT DISTINCT O.codigo
FROM O in OBRA
WHERE O.localizacao = "Porto"
As BDOO têm várias vantagens. O novo modelo de dados é mais baseado no
mundo real, facilitando a sua compreensão. Como os objectos não precisam de ser
“compostos” a partir das suas tabelas, o tempo necessário para o processamento é
bastante reduzido. A reutilização de objectos reduz os custos de desenvolvimento, e o
controlo de concorrência é simplificado, porque é possível colocar um lock numa
classe, mas mantendo ainda assim a capacidade de colocar um lock num objecto
individual. E, muito importante para este estudo, adaptam-se bem ao modelo
distribuído.
Porém, este modelo também acarreta alguns problemas: alguns acessos podem
ser mais lentos (cálculo de médias de valores existentes na BD, por exemplo) e a falta
59
Bases de Dados Distribuídas
de standards suficientemente difundidos (a OQL pode ser a solução para este
problema) são duas desvantagens importantes.
Objecto
OBRA = 1
Obra
ORCAMENTO = 300000,00
EMPREGADOS
next
next
nil
Objecto
Empregado
EMPREGADO = 1
NOME = F.Rodrigues
EMPREGADO = 3
NOME = A. Silva
OBRA
Figura 17: Modelo dos Objectos da Relação Obra-Empregados
Bases de Dados Objecto-Relação
Este modelo é uma evolução do modelo relacional e manteve a
compatibilidade com este. Foi introduzido um novo modelo de dados, que permite a
criação de tipos de tuplos (possibilidade de estruturas complexas e hierarquias) e de
tipos abstractos. Também foram introduzidas alterações na SQL2, dando origem à
SQL3. Com a SQL3 é possível procurar referências, indicar OIDs, aceder a estruturas
internas e aninhar e desaninhar objectos.
Um exemplo de aninhação :
SELECT localizacao, SET(nome)
FROM EMPREG
GROUP BY localizacao
Bases de Dados de 3ª Geração
Foram uma resposta à necessidade de envolver o modelo de dados relacional,
mantendo a compatibilidade e, ao mesmo tempo, permitir a definição de objectos e
regras complexas. As BDs multimédia por exemplo, permitem fazer inquéritos com a
60
Bases de Dados Distribuídas
mesma estrutura do SQL (à parte estruturada da informação) e outros inq uéritos
baseados em condições de semelhança (que necessitam de técnicas ad-hoc e,
normalmente, produzem resultados probabilísticos). Por exemplo, a procura de
documentos na Internet necessita de:
? Técnicas comuns (procura por palavras chave, exclusão de out ras);
? Mudar a implementação conforme a língua;
? Indicadores de qualidade da procura (percentagem de documentos
relevantes entre os extraídos, percentagem de documentos relevantes entre
os documentos relevantes existentes na BD);
? Técnicas físicas (matrizes e índices, por ex.).
Já na representação de dados espaciais (GIS), o maior problema é encontrar
uma estrutura de dados que permita responder eficientemente aos inquéritos.
A tecnologia de BDs com base no paradigma Object Oriented coloca uma
série de que stões de implementação:
? A representação de objectos pode ser do tipo horizontal (onde cada
objecto é colocado junto à classe a que pertence) ou vertical (onde os
objectos são divididos nas suas propriedades e estas são guardadas
adjacentemente). Porém, não pode existir fragmentação nestes sistemas, já
que isso poria em causa o encapsulamento. A fragmentação deve mesmo
ser proibida através de restrições de integridade explícitas;
? A representação dos identificadores pode utilizar um endereço físico ou
um surrogate (um valor simbólico único, associado ao objecto, o que
implica a criação de estruturas de acesso adequadas);
? Índices complexos que permitam procura directa ou inversa. Cada tipo de
dados deve ter mecanismos de índices próprios;
? A arquitectura cliente/servidor foi modificada, permitindo o uso de
operações de check in e check out de objectos. Os clientes podem importar
os objectos e manipulá- los localmente.
Tal como no modelo relacional, o acesso à BDD é controlado através de uma
classificação dos seus elementos. O elemento básico de classificação é o objecto. O
61
Bases de Dados Distribuídas
acesso é permitido se o utilizador tiver acesso aos métodos do objecto. Uma vantagem
que este modelo tem sobre o relacional é a existência de encapsulamento: as
instâncias de objectos remotos não têm acesso aos dados do objecto invocado,
mantendo mais facilmente a sua integridade.
O controlo de acesso pode ser feito no nó origem de um modo semelhante ao
do modelo relacional. Porém, como não há uma definição clara de cliente e servidor
nestes sistemas, o controlo de acesso realizado nos nós remotos é impraticável,
acarretando a desvantagem já apresentada (maior probabilidade de acessos não
autorizados).
62
Bases de Dados Distribuídas e SQL Server
3. O Microsoft S QL Se rve r
Tendo em vista as necessidades das empresas, os criadores de servidores de
bases de dados apressaram-se a fornecer suporte às BDDs. As empresas cujos
servidores estão mais implantados no mercado (Microsoft, Oracle, IBM e Sybase) já
têm soluções que respondem a algumas das necessidades das empresas que desejam
distribuir os seus dados e o seu processamento.
Empresa
Produto
Características mais importantes
IBM
DataPropagator Relational
Adaptada à DB2;
(DpropR)
Replicação assíncrona e de primary site;
Nós read-only subscrevem para o primary
site;
Subscrição de subconjunto ou resultado da
query.
Distributed Relational Database
BDs heterogéneas.
Arquitecture (DRDA)
DataJoiner
Middleware para acesso a BDs de outros
fabricantes.
Sybase
Replication Server
Nó primary site e nós read-only distribuídos;
Replicação síncrona;
Replicação hierárquica;
Dados e stored procedures replicados.
Oracle
SQL Anywhere
BDs móveis.
OmniSQL
BDs heterogéneas.
Table Snapshot Option
Snapshots periódicos enviados para os nós
read-only;
Symmetric Replication Option
Replicação síncrona e assíncrona de qualquer
nó para qualquer outro nó;
Refrescamento diferencial;
Agentes controlam a replicação;
Two-Phase Commit.
63
Bases de Dados Distribuídas
Microsoft
Microsoft SQL Server
Nó primary site e nós read-only distribuídos;
Modelo com publicadores e subscritores;
Uma BD pode passar cópias de publicações
para outros nós;
BDs móveis.
Tabela 13: produtos BDD e suas características mais importantes.
Uma vez que o exemplo que irá ser apresentado neste trabalho irá utilizar o
Microsoft SQL Server, passa-se a apresentar com maior pormenor esta solução da
Microsoft Corp.
3.1 Replicação no Microsoft SQL Server
O modelo de replicação utilizado baseia-se no conceito de Publicadores e
Subscritores. Um publicador é o servidor que disponibiliza a outros servidores dados
para replicação. Adicionalmente detecta quais foram as alterações aos dados e
mantém informação sobre todas as suas publicações. Um subscritor é um servidor que
guarda os dados replicados e recebe as alterações. Um distribuidor é um servidor que
contém metadados, registos históricos e transacções (estas últimas para publicações
transaccionais).
Uma publicação é um conjunto de dados a ser replicado. Estes dados podem
ser provenientes de uma tabela, de um fragmento de uma tabela ou pode até ser um
stored procedure. As subscrições dividem-se em dois tipos: push (subscrição
“empurrada”) e pull (subscrição “puxada”). No primeiro tipo, o publicador propaga as
alterações sem a existência de um pedido para o fazer. Já no segundo tipo, o
subscritor pede periodicamente as actualizações ao publicador.
Um immediate updating subscriber é um subscritor que pode actualizar um
determinado conjunto de dados, assim como o publicador. Porém, quando altera os
dados, tem de reflectir essa actualização imediatamente para o publicador (e outros
subscritores do tipo immediate updating que eventualmente existam), numa
transacção utilizando o protocolo Two-Phase Commit (2PC). O 2PC é controlado pelo
Microsoft Distributed Transaction Coordinator (MSDTC). Depois de a alteração ser
publicada no Publicador, vai ser publicada em todos os subscritores desta publicação.
64
Bases de Dados Distribuídas e SQL Server
Esta tarefa pode não ser logo efectuada, mas apenas aquando da próxima actualização
agendada.
Existem três tipos de replicação no Microsoft SQL Server:
-
snapshot – quando existem poucos dados numa relação ou quando estes
não são actualizados com muita frequência;
-
transaccional – quando as actualizações são mais frequentes ou quando o
volume de dados é muito grande para ser actualizado de uma vez só;
-
merge – quando todos os servidores podem alterar os dados, funcionando
como publicadores e subscritores ao mesmo tempo.
Na mesma aplicação podem usar-se diferentes tipos de replicação, dependendo
das necessidades de consistência dos dados, da autonomia dos nós e dos recursos ao
nível da rede.
A replicação snapshot é o tipo de replicação mais simples. É recolhida uma
imagem da BD num dado momento e enviada aos subscritores, o que, no caso de
grandes volumes de dados, requer recursos substanciais da rede. Ao contrário da
publicação do tipo transaccional (que envia as operações aos dados) ou da publicação
do tipo merge (que envia as modificações aos dados), o snapshot não necessita de
uma monitorização constante das alterações aos dados, sobrecarregando menos a
máquina de replicação. Os subscritores são do tipo read-only, ou seja, apenas podem
ler os dados, nunca actualizá- los. A consistência não deve ser um requisito constante e
obrigatório, porque os dados podem não ser imediatamente publicados em todos os
subscritores. Os snapshots podem ser agendados para determinadas alturas do dia,
aproveitando, preferencialmente, as alturas de baixa actividade dos nós. A opção
immediate updating subscribers pode aplicar-se a este tipo de replicação.
Os nós publicadores na replicação transaccional não enviam todos os dados
para os subscritores, mas sim as operações efectuadas sobre esses dados. Quando o
subscritor requisita os dados pela primeira vez, é necessário copiar a publicação
actual, completamente, do publicador para o subscritor. A este processo dá-se o nome
de aplicação de sincronização. Depois, o transaction log é utilizado para captar as
65
Bases de Dados Distribuídas
operações que vão afectando os dados (INSERT, UPDATE, DELETE...), e estas são
propagadas (normalmente em tempo real) para os subscritores e aplicadas
ordenadamente. A opção immediate updating subscribers pode aplicar-se a este tipo
de replicação.
A replicação do tipo merge sincroniza as alterações entre o publicador e os
subscritores que possam efectuar alterações aos dados. O publicador não impõe
automaticamente as suas alterações em caso de conflito: o “desempate” é determinado
por critérios pré-estabelecidos. Estes critérios podem ser, por exemplo, regras de
prioridade: a actualização efectuada primeiro é a que prevalece. Da mesma forma que
na replicação do tipo transaccional, é necessário obter um snapshot inicial (a
publicação corrente) do esquema e dados da tabela. Este esquema favorece a
autonomia, porém a consistência transaccional não está garantida. Ou seja, o valor
final que irá ser guardado nas BDs poderá não ser igual ao valor que seria obtido se
todas as alterações tivessem sido efectuadas num único nó. Assim, se a aplicação
necessitar de integridade, mas não a puder garantir, este tipo de replicação não deverá
ser utilizado.
Os conflitos são detectados através de uma coluna chamada “lineage”, que
representa a história das alterações numa linha. Aquando de uma actualização, se uma
determinada linha foi alterada recentemente, a lineage em cada nó é verificada. Se
houver algum conflito, é feita uma reconciliação automática.
A figura abaixo mostra as diferenças entre os vários tipos de replicação, em
termos de autonomia dos nós e consistência transaccional obtida:
66
Bases de Dados Distribuídas e SQL Server
Autonomia dos nós
Consistência Transaccional
Replicação
Repl. Tran-
Repl.
Immediate
Distributed
Merge
saccional
Snapshot
Updating
Transaction
Subscriber
Coordinator
Figura 18 : Diferentes Tipos de Replicação em termos de autonomia dos nós e consistência
transaccional 18
3.2 Fragmentação no Microsoft SQL Server
A fragmentação é possível no Microsoft SQL Server. Para uma determinada
tabela, são criadas as chamadas tabelas- membro, cada uma com um conjunto dos
tuplos da tabela original. Depois, são criadas partitioned views (vistas fragmentadas),
uma em cada servidor que contenha uma tabela- membro. As vistas, no SQL Server
podem ser do tipo local, ou do tipo distribuído. As vistas do tipo local obtêm todos os
seus dados em fragmentos existentes no servidor local; as do tipo distribuído têm de
recorrer a pelo menos um fragmento remoto. Além disso, as vis tas podem ser
actualizáveis ou read-only.
As vistas fragmentadas de cada tabela devem ter o mesmo nome em todos os
servidores. Assim, os inquéritos que invoquem a vista, podem- na invocar da mesma
maneira em qualquer servidor, facilitando a transparência em termos de localização.
Vamos considerar, por exemplo, uma BDD com dois servidores (serv1 e
serv2). Pretende-se fragmentar uma tabela com o nome TOMADOR, cuja chave é o
campo tomID.
18
Ajuda On-Line da Microsoft – MSDN Library, October 2001
67
Bases de Dados Distribuídas
Em serv1:
CREATE TABLE tomador_1
( tomID INTEGER PRIMARY KEY CHECK(tomID BETWEEN 1 and 500),
... (restantes definições das colunas da tabela) )
Em serv2 :
CREATE TABLE tomador_2
( tomID INTEGER PRIMARY KEY CHECK(tomID BETWEEN 501 and 1000),
... (restantes definições das colunas da tabela) )
Depois de se criar os fragmentos, deve-se criar uma linked server definition
para serv2. Uma linked server definition é uma ligação para outro servidor contendo
informação de conexão. Uma vez criada esta ligação é possível criar as particioned
views:
Em serv1:
CREATE VIEW tomador AS
SELECT * FROM db1.tomador_1
UNION ALL
SELECT * FROM serv2.db1.tomador_2
Deve-se fazer algo semelhante em serv2.
A fragmentação vertical também é possível, mas as regras de particionamento
são bastante restritas, de modo a fazer respeitar as regras de integridade. Só pode ser
aplicada uma única restrição à coluna de particionamento. Todas as outras restrições
serão ignoradas.
Depois de as vistas terem sido criadas, acede-se aos dados através delas. Como
já foi referido, as vistas podem ser actualizáveis, devendo para isso ser estruturadas
utilizando a expressão UNION ALL, como no exemplo atrás referido. Se a vista se
referir a uma única tabela, ou seja, não existe fragmentação, a vista também é
actualizável. Assim, as operações de INSERT, UPDATE e DELETE são aplicadas à
vista, que se encarrega de alterar a tabela correspondente. Estas operações, para terem
sucesso, devem obedecer a um conjunto de regras.
68
Bases de Dados Distribuídas e SQL Server
As regras para a operação de INSERT em tabelas são as seguintes:
? Todas as colunas devem ser incluídas no INSERT, mesmo que a coluna
possa ser NULL na tabela base, ou mesmo que exista uma restrição
DEFAULT definida na tabela base;
? A expressão DEFAULT não pode ser utilizada;
? O valor da coluna de particionamento deve respeitar a lógica da restrição
CHECK que existir para essa coluna;
? Os INSERTs não são permitidos se na tabela base existir uma coluna com
a propriedade identidade;
? Os INSERTs não são permitidos se a tabela membro contiver uma coluna
timestamp;
? Os INSERTs não são permitidos se houver um self-join com a mesma
vista ou qualquer uma das tabelas base.
As regras para a operação de UPDATE em tabelas são as seguintes:
? Os UPDATEs não podem utilizar um DEFAULT, mesmo que a coluna
tenha essa palavra chave na sua definição;
? O valor da coluna com a propriedade identidade não pode ser alterado:
contudo, as outras colunas podem;
? O valor da chave primária não pode ser alterado se a coluna contiver dados
do tipo text, image ou ntext;
? Os UPDATEs não são permitidos se a tabela base contiver uma coluna
timestamp;
? Os UPDATEs não são permitidos se houver um self-join com a mesma
vista ou qualquer uma das tabelas base;
? A palavra chave DEFAULT não pode ser especificada na cláusula SET do
UPDATE.
Existe uma única regra para a operação de DELETE em tabelas:
? Os DELETEs não são permitidos se houver um self-join com a mesma
vista ou qualquer uma das tabelas base.
69
Bases de Dados Distribuídas
3.3 Transacções no Microsoft SQL Server
Devido às dificuldades levantadas pela gestão de transacções distribuídas, a
Microsoft criou o Microsoft Transaction Server (MTS). Este tem um interface
simples, de modo a facilitar a compreensão do utilizador ao mesmo tempo que gere
eficientemente as transacções. O MTS define um modelo de programação para
desenvolver aplicações distribuídas. Estas são construídas utilizando controlos Active
X, e depois a infraestrutura de gestão das transacções é- lhes adicionada. Assim, as
soluções criadas são as mais adequadas a cada caso.
Além de ajudar no desenvolvimento da aplicação, o MTS realiza outras tarefas
de suporte:
? Gere os recursos de baixo-nível dos sistemas (processos e threads, por
exemplo);
? Sincroniza os acessos aos dados partilhados;
? Guarda informações sobre os utilizadores para que o trabalho de uns não
interfira com o dos outros;
? Gere a segurança do sistema;
? Gere e configura as aplicações de modo a que estas se adaptem às
necessidades dos utilizadores.
A transparência transaccional é suportada: a transacção é gerida internamente
pelo SQL Server, quase como se fosse local. A maior diferença reside no processo de
COMMIT, controlado como auxílio do 2PC. Para este passo é utilizado o Microsoft
Distributed Transaction Manager (ou outro que suporte a especificação X/Open/XA).
Este tem a função de coordenar os gestores de recursos 19 de todos os servidores que
participam na transacção. O próprio SQL Server pode funcionar como gestor de
recursos. Os nós têm de estar disponíveis e ligados à rede, o que reduz a sua
autonomia. Mais tarde, numa outra transacção, os dados são publicados para os
restantes subscritores, num exemplo de replicação assíncrona ou lazy. Esta
actualização aos outros servidores pode ser agendada para um determinado período do
dia, ou pode ser imediatamente realizada. Para a detecção de conflitos é utilizado um
mecanismo de timestamp.
19
Um gestor de recursos é o software que controla cada recurso da transacção distribuída.
70
Bases de Dados Distribuídas e SQL Server
Uma transacção pode ser despoletada de duas formas: através de comandos de
TRANSACT-SQL (normalmente um script delimitado pelos comandos “BEGIN
DISTRIBUTED TRANSACTION” e “COMMIT/ABORT TRANSACTION”), ou
através de uma stored procedure escrita numa qualquer linguagem de programação.
Para o suporte às transacções, a Microsoft colocou ao dispor o SQL-DMO
(Distributed Management Objects). Os objectos de SQL-DMO podem ser invocados
por qualquer linguagem que suporte COM e OLE 2.0. O seu objectivo é definir todos
os aspectos da BD e seus serviços: bases de dados, regras, triggers, tabelas, etc. Mais
abaixo pode ver-se um exemplo em Visual Basic da definição de um objecto SQLDMO e sua conexão a um servidor com
nome “NomeServidor”, login “sa” e
password “ ”:
Dim ServerObject As New SQLOLE.SQLServer
ServerObject.Connect “NomeServidor”, “sa”, “ ”
3.4 Processamento Distribuído de Questões no
Microsoft SQL Server
As opções para o processamento distribuído de questões devem ser definidas
através do SQL Server Enterprise Manager. Este é um interface gráfico que dá acesso
a todas as funcionalidades da BD, sem que seja necessário introduzir comandos SQL.
Estas opções podem pertencer a dois níveis: o nível do provider OLE DB,
configuradas no registry do sistema operativo, ou o nível do servidor ligado (linked
server). As opções ao nível do provider afectam todas as definições de servidores
ligados que usem o mesmo provider OLE DB. Ao nível do provider temos a
possibilidade de permitir inquéritos aninhados ou parametrizados e acessos ad-hoc,
entre outras. Ao nível do servidor ligado, é possível definir timeouts no acesso a
servidores, por exemplo.
Mesmo que os servidores não sejam ligados, é possível executar inquéritos
distribuídos. Porém, em vez de o Microsoft Distributed Transaction Manager
(MSDTC) tratar o inquérito como distribuído, são lançados stored procedures no
servidor remoto, como parte da transacção distribuída.
71
Bases de Dados Distribuídas
Já ao nível da optimização de inquéritos distribuídos, o SQL Server realiza
dois tipos de optimização específicos:
? execução remota de inquéritos com os OLE DB SQL Command Providers;
? acesso indexado com os OLE DB Index Providers.
O primeiro tipo de optimização tenta dividir o inquérito e passar os subinquéritos que afectam dados remotos para o servidor que contém esses mesmos
dados, de modo a reduzir o número de tuplos retornados.
O segundo tipo de optimização tenta utilizar os índices do Index Provider para
avaliar condições e realizar operações de ordenação em tabelas remotas, de modo a
realizar rapidamente as procuras à BD.
Existe uma ferramenta gráfica, o SQL Query Analyzer, que mostra o plano de
execução de um dado inquérito. Os sub- inquéritos remotos são assinalados para uma
maior percepção daquilo que se está a passar.
72
O caso GIS Mediadores
4. O caso GIS Mediadore s
O software GIS Mediadores é um conjunto de sub- módulos integrados sob um
interface de gestão. Os módulos são adicionados ao conjunto consoante as
necessidades do mediador. Também a BD de suporte terá mais ou menos tabelas
consoante os módulos adicionados. Algumas das tabelas podem ver-se a seguir:
TOMADOR(tomador, nome, morada, idade, num_contrib,...)
PRODUTO(produto, codigo, designacao, abreviatura...)
COMPANHIA(companhia, codigo, designacao, morada ...)
SEGURO(seguro, regime, tomador, data de inicio, data de termo ...)
RECIBO(recibo, seguro, produto, companhia, apolice, tomador...)
Um cenário típico é o de um mediador cuja sede tem uma base de dados
com estas tabelas (e muitas outras, com certeza, mas que de momento não têm
interesse para este trabalho). Espalhados pelo país existem outros mediadores
a realizar algumas operações de cobrança e angariação de novos clientes.
Os mediadores-filial (chamemos-lhes assim) têm na sua própria BD algumas
das tabelas existentes na BD do mediador-sede, provavelmente fragmentadas por
situação geográfica, ou seja, fragmentadas pela localização do mediador. A
fragmentação não será apenas horizontal, mas mista, pois os mediadores não precisam
de aceder a todos os dados que a BD da sede contém, mas apenas aos mais
importantes.
As tabelas TOMADOR, SEGURO e RECIBO serão actualizadas por todos os
nós envolvidos (cada servidor actualizará o fragmento local, minimizando assim a
possibilidade de conflitos). A tabela PRODUTO será actua lizada apenas na
sede, já que novos produtos serão lançados pela sede e nunca por um mediador-filial.
A tabela COMPANHIA terá um processamento semelhante à tabela PRODUTO,
73
Bases de Dados Distribuídas
já que apenas a sede terá autorização para trabalhar com novas companhias,
um mediador-filial nunca poderá tomar essa liberdade.
O tipo de replicação mais adequado para as tabelas SEGURO, RECIBO e
TOMADOR será a do tipo merge, já que permite que qualquer nó actualize os dados,
incluindo nós móveis. Como os dados estão fragmentados por área geográfica e só a
sede tem todos os dados, os conflitos serão minimizados, de modo a garantir a
consistência dos dados. Relembra-se que a replicação do tipo merge não garante a
consistência: a aplicação é que a deve garantir.
As tabelas que não são alteráveis pelas filiais (tabelas PRODUTO e
COMPANHIA), serão alteradas apenas na sede. Essas alterações serão depois
publicadas seguindo a estratégia snapshot, numa subscrição do tipo push. Já que todos
os mediadores devem saber os produtos existentes, não há necessidade de pedirem as
actualizações a esta tabela: os dados são- lhes imediatamente enviados.
Para que estas tabelas sejam replicadas, é necessário criar uma publicação no
servidor da sede. Para este passo existe um wizard que guia o utilizador, explicando
todas as alternativas existentes para a criação de uma publicação.
Figura 19 : Publicações existentes no servidor
74
O caso GIS Mediadores
As propriedades da publicação podem facilmente ser alteradas para reflectir as
necessidades da aplicação. Como já foi explicado, cria-se um snapshot inicial para
que o subscritor contenha o esquema da BD e os dados das tabelas. Isso pode ser feito
na tab "Status", fazendo correr o agente do snapshot.
Figura 20 : Propriedades de uma publicação
No servidor do subscritor cria-se uma pull subscription para os dados da tabela
TOMADOR, RECIBO e SEGURO, com a ajuda de um wizard, que, como no caso da
publicação, ajuda o utilizador a configurar a subscrição que pretende.
Na prática, este esquema é um pouco difícil de gerir, pois as actualizações
implicam quase sempre a existência de conflitos. Por exemplo, o caso de um
mediador que introduz na tabela TOMADOR um registo com dados do tomador com
código 1. Na sede, é possível que nesse momento, esteja a ser introduzido um registo
na tabela TOMADOR, também com esse código. Quando as alterações do mediador
são enviadas para a sede e é feito o merge da tabela, os dados que o mediador
75
Bases de Dados Distribuídas
introduziu entrarão em conflito com os que entretanto foram introduzidos na sede.
Um dos registos será necessariamente descartado, mas irá ser registado numa tabela
do
sistema,
cujo
nome
obedece
aos
seguintes
critérios:
conflit_<NomeDaPublicação>_<NomeDaTabela>. Esta tabela irá possibilitar que os
dados não sejam completamente perdidos: é possível criar um programa que, aquando
da existência de conflitos verifica essa tabela e recupera os dados, inserindo-os na
tabela TOMADOR, desta vez com outro código.
Figura 21 : O Replication Conflict Viewer ajuda à visualização dos conflitos existentes durante a
fase de junção das BDs.
Este processamento pode introduzir muito overhead, porque quem introduziu
os dados do tomador, deve ter introduzido dados noutras tabelas, com informação
baseada num código que, afinal, foi alterado. É necessário actualizar também essas
tabelas de modo a que não existam inconsistências no final.
Isto seria feito num módulo à parte, mas já dentro do GIS Mediadores.
Quando o programa detectasse que tinham existido conflitos na fase do merge,
lançaria um procedimento que iria repor os dados. No fim informava o utilizador das
76
O caso GIS Mediadores
alterações efectuadas. Se existissem conflitos que o programa não conseguisse
resolver, informaria o utilizador e esperaria por uma decisão.
A replicação, como já foi indicado anteriormente, traz mais benefícios quando
os dados são lidos muitas vezes pelos servidores remotos, mas poucas vezes
actualizados, devido à carga adicional que é colocada sobre o sistema para manter as
réplicas consistentes.
77
Conclusões
5. Conclusõe s
Este trabalho abordou o tema das Bases de Dados Distribuídas.
Em primeiro lugar foram apresentados os conceitos teóricos: desde a
arquitectura de uma BDD até ao processamento distribuído de questões, passando
pelas alternativas de replicação e gestão de transacções distribuídas. As novas
configurações não foram esquecidas: as BDs móveis e aquelas baseadas no paradigma
Object Oriented. As BDs móveis têm especial interesse para este trabalho devido à
sua utilização no cenário GIS Mediadores.
De seguida apresentou-se a solução da Microsoft para a gestão de um sistema
servidor de BD que suporte distribuição. Os pormenores de implementação,
replicação, gestão de transacções e de inquéritos distribuídos foram clarificados para
melhor se perceber o trabalho prático efectuado.
Por último, simulou-se a criação de uma publicação num servidor de BD e de
uma subscrição noutro servidor de modo a que estes pudessem trocar dados. O
trabalho que seria efectuado num cenário real seria em tudo semelhante ao efectuado
aqui.
O modelo das Bases de Dados Distribuídas é, de facto, o melhor para o caso
de grandes corporações que desejam distribuir os seus dados e o seu processamento
por áreas geográficas dispersas. Replicando e fragmentando os dados, alcançando
novas maneiras de os gerir e processar inquéritos, tem-se o melhor desempenho,
respeitando as necessidades de cada aplicação em termos de autonomia e acesso aos
dados. O crescimento do número de utilizadores móveis a que se tem assistido
também irá desempenhar um papel importante, já que a melhor solução para o seu
caso também passa pelas BDDs. Permitindo que estes tenham acesso aos dados das
outras BDs e os possam alterar, mesmo desconectados, cria-se uma nova estratégia
mais adequada ao seu trabalho e às condições em que o efectuam. Espera-se que os
conceitos principais tenham sido clarificados de modo a dar a entender o grande
potencial que este modelo tem.
79
Bases de Dados Distribuídas
Bibliograf ia
Livros:
PEREIRA, José Luís – Tecnologia de Bases de Dados, Lisboa, FCA - Editora
de Informática, 2ª edição actualizada e aumentada, Outubro de 1998.
Revistas:
Personal Computer World – Ed. Portuguesa, nº 159 de Março de 2000, vol.
14.
Ajuda on- line da Microsoft (MSDN) – Federated Databases
Sites na Internet:
http://bridge.ecn.purdue.edu/~yiguo/dropbox/w2000.pdf
http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper072_073_074/
SCO_.PDF
http://domino.research.ibm.com/cambridge/research.nsf/
2b4f81291401771785256976004a8d13/c71ebac11ec6e54f8525661600797829/$FI
LE/mobile.pdf
http://ftp.research.microsoft.com/pub/debull/A00JUN_CO.pdf
http://geog-www.sbs.ohio-state.edu/faculty/ mkwan/Paper/jdm_2000.pdf
http://hst.home.cern.ch/hst/phd.htm
http://ipdps.eece.unm.edu/1998/wpdrts/kylam.pdf
http://sistemas.ing.ula.ve/sistemas/bd/bdDist.pdf
http://storacle.princeton.edu:9001/oracle8-doc/ server.805/a58247/toc.htm
http://technet.oracle.com/deploy/performance/pdf/FederatedvsClustered.pdf
http://vyaskn.tripod.com/federated.htm
http://www.ccs.neu.edu/home/salzberg/com3560/
http://www.chest.ac.uk/software/objectivity/docs/technical-overview.html
http://www.comp.nus.edu.sg/~cs5225/
http://www.computing.surrey.ac.uk/personal/st/D.Barton/CS363/2-DistribDB4up.pdf
81
Bases de Dados Distribuídas
http://www.cs.adfa.oz.au/teaching/studinfo/dsd/index.html
http://www.cs.mcgill.ca/~kemme/cs577/main.html
http://www.cs.purdue.edu/AnnualReports/95/AR95Book-74.html
http://www.cs.rutgers.edu/dataman/papers/vldb92.pdf
http://www.cs.ualberta.ca/~database/ddbook.html
http://www.cs.wustl.edu/~schmidt/corba-overview.html
http://www.csse.monash.edu.au/courseware/cse5200
http://www.csse.monash.edu.au/courseware/cse5501/
http://www.ctit.utwente.nl
http://www.ctit.utwente.nl/programme/disciplines/db.html
http://www.db.uwaterloo.ca/~tozsu/ddbook/notes.html
http://www.dcs.bbk.ac.uk/WebDyn/WebDynPapers/ishikawa.pdf
http://www.dis.port.ac.uk/~chandler/OOLectures/database/database.htm
http://www.eecs.umich.edu/courses/eecs684/
http://www.engr.smu.edu/~mhd/8391f01/MCDBpresentation.ppt
http://www.ifip.or.at/con2000/icct2000/icct382.pdf
http://www.prato.linux.it/~gbartolini/pdf/mysql.pdf
http://www.sei.cmu.edu/str/descriptions/com.html
http://www.unab.edu.co/editorialunab/revistas/rcc/r21_art2_c.pdf
http://www-2.cs.cmu.edu/afs/cs/project/coda/Web/docdir/
http://www-hbp.usc.edu/LAB/cshahabi.html
http://wwwinfo.cern.ch/db/aboutdbs
http://xerox.elet.polimi.it/dbbook/slides.html
82
Bases de Dados Distribuídas
Glossário
Adaptabilidade – característica de um módulo de software que consegue satisfazer
exigências de diferentes sistemas e necessidades de diferentes utilizadores.
Consistência – qualidade dos dados que estão de acordo com as restrições de
integridade da base de dados onde se encontram armazenados.
Consistência Transaccional – depois de ser efectuada uma transacção distribuída, os
resultados serão iguais aos obtidos por uma transacção efectuada num único nó.
Interoperabilidade – a capacidade que dois os mais sistemas ou componentes têm de
trocar informação e de utilizar essa mesma informação.
Manutenibilidade – a facilidade com que um sistema ou componente de software
pode ser manutenível, isto é, pode ser modificado para corrigir falhas, melhorar o
desempenho (ou outros atributos), ou até mesmo ser adaptado a um ambiente diverso.
Reutilizabilidade – característica de um módulo de software ou outro produto que
pode ser utilizado em mais do que uma aplicação ou sistema de software.
Seriazibilidade – quando várias transacções estão a ser executadas concorrentemente,
os resultados devem ser iguais àqueles obtidos quando as transacções são executadas
em série, numa determinada ordem.
83
Bases de Dados Distribuídas
Índice Remissivo
2
2PC (Two-Phase Commit), 37, 38, 39, 64, 70, 87,
99
P
Processamento distribuído de questões, 19, 42, 43,
44, 71, 79
2PL (Two-Phase Locking), 40, 87
R
A
Replicação, 2, 11, 19, 22, 23, 24, 25, 26, 34, 55, 56,
Alocação, 2, 21, 34, 41, 43
63, 64, 65, 66, 70, 74, 77, 79
Arquitectura cliente/servidor, 61
T
F
Timestamp, 26, 40, 41, 57, 69, 70
Fragmentação, 2, 11, 18, 19, 21, 28, 29, 30, 31, 32,
34, 43, 46, 47, 61, 67, 68, 73
Transacção, 19, 23, 24, 25, 35, 36, 37, 38, 39, 40,
41, 56, 57, 64, 70, 71, 83, 100
Transacção distribuída, 35, 70, 71, 83
85
Bases de Dados Distribuídas
Siglas
2PC
Two-Phase Commit
2PL
Two-Phase Locking
API
Application Program Interface (Interface de Programação de Aplicações)
BD
Base de Dados
BDD
Base de Dados Distribuída
IDL
Interface Definition Language (Linguagem de Definição de Interfaces)
MSDTS Microsoft Distributed Transaction Server
MTS
Microsoft Transaction Server
SGBD
Sistema Gestor de Base de Dados
SQL
Structured Query Language (Linguagem de Inquéritos Estruturada)
LAN
Local Area Network (Rede de Área Local)
WAN
Wide Area Network (Rede de Área Alargada)
87
Bases de Dados Distribuídas
Anexos
A1 - CORBA20
A Common Object Request Broker Architecture (CORBA) é uma infrastrutura
aberta de distribuição de objectos de computação, que se tem vindo a tornar um
standard, criada pelo OMG (Object Management Group). O CORBA automatiza
muitas tarefas de programação da rede tais como registar, posicionar e activar um
objecto; desmultiplicação de pedidos; criação de frames e manipulação de erros;
marshalling e unmarshalling de parâmetros; e despacho de operações.
A figura seguinte ilustra os componentes preliminares da arquitectura do
Modelo da Referência do OMG. As descrições destes componentes estão disponíveis
mais abaixo.
Figura 22 : Arquitectura do Modelo de Referência da OMG
? Serviços do Objecto -- São interfaces independentes do domínio, usados por
muitos programas de objectos distribuídos. Por exemplo, um serviço que
descobre outros serviços disponíveis é quase sempre necessário, qualquer que
seja o domínio da aplicação. Dois exemplos de Serviços do Objecto que
cumprem este papel são:
o Serviço nomeadores - permitem que os clientes encontrem objectos
baseados em nomes;
o Serviço negociadores - permitem que os clientes encontrem
objectos baseando-se nas suas propriedades.
20
Baseado na informação disponível no site http://www.cs.wustl.edu/~schmidt/corba-overview.html
89
Bases de Dados Distribuídas
Existem também especificações de Serviços do Objecto para a gestão do ciclo
de vida, da segurança, de transações e notificações de eventos, assim como
muitos outros.
?
Common Facilities (facilidades comuns) – Tal como os interfaces de Serviço
do Objecto, são também orientados horizontalmente, mas ao contrário dos
Serviços do Objecto o seu objectivo são as aplicações do utilizador final. Um
exemplo é o Distributed Document Component Facility (Componente
Distribuído do Documento - DDCF), uma facilidade criada a partir da
Common Facility, baseada em OpenDoc. O DDCF permite a apresentação e o
intercâmbio de objectos baseados num modelo de documento, por exemplo,
facilitando a ligação de um objecto spreadsheet com um relatório.
?
Interfaces do Domínio -- Estes interfaces fornecem serviços semelhantes aos
dos Serviços do Objecto e dos Common Facilities, mas são orientados para
domínios específicos da aplicação. Por exemplo, um dos primeiros RFPs do
OMG emitidos para Interfaces do Domínio é orientado para o domínio do
fabrico (Product Data Management Enablers – serviços de gestão de produtos
de dados). Outros RFPs da OMG serão emitidos para os domínios das
telecomunicações, médicos, e financeiros.
?
Interfaces da Aplicação -- Desenvolvidas especificamente para uma dada
aplicação. Porque são específicas às aplicações, e porque o OMG não
desenvolve aplicações (somente especificações), estes interfaces não são
standard. Porém, se serviços úteis para outras aplicações emergirem de um
domínio particular, podem tornar-se candidatos a serem standars futuros da
OMG.
CORBA ORB Architecture
A seguinte figura ilustra os componentes principais da arquitectura do
CORBA ORB.
Figura 23: Arquitectura CORBA ORB
90
Bases de Dados Distribuídas
?
Objecto -- Entidade de programação do CORBA, composta por uma
identidade, uma interface e uma implementação, conhecida por Servant.
?
Servant (empregado) -- Entidade da linguagem de programação da
implementação que define as operações que suportam um interface de
CORBA IDL. Os servants podem ser escritos numa grande variedade de
linguagens, incluindo C, C++, Java, Smalltalk, e Ada.
?
Cliente -- Entidade do programa que invoca uma operação de uma
implementação do objecto. Invocar os serviços de um objecto remoto deve ser
transparente para o invocador. Idealmente, deve ser tão simples quanto
chamar um método num objecto, isto é, obj->op(args). Os componentes
restantes na figura 2 ajudam a suportar este nível de transparência.
?
Object Request Broker (ORB) -- O ORB fornece um mecanismo para
comunicar de um modo transparente pedidos de clientes para as
implementações de objectos. O ORB simplifica a programação distribuída ao
libertar cliente dos detalhes da invocação dos métodos. Isto faz com que os
pedidos dos clientes pareçam ser chamadas locais aos procedimentos. Quando
um cliente invoca uma operação, o ORB é responsável por encontrar a
implementação do objecto, activando-a transparentemente se necessário,
entregando o pedido ao objecto, e retornando as respostas ao invocador.
?
Interface ORB -- Um ORB é uma entidade lógica que pode ser implementada
de várias maneiras (tal como um ou mais processos ou conjunto de
bibliotecas). Para libertar as aplicações dos detalhes da implementação, a
especificação do CORBA define uma relação abstracta para um ORB. Esta
interface fornece várias funções de suporte tais como conversões de
referências de objectos para strings e versa vice; criação de listas de
argumentos para pedidos feitos através do interface dinâmico de invocação
descrito abaixo.
?
Stubs and skeletons do CORBA IDL -- os stubs e os skeletons do CORBA
IDL são como que a “cola” entre o cliente e as aplicações do servidor,
respectivamente, e o ORB. A transformação entre definições de CORBA IDL
e a linguagem de programação alvo é automatizada por um compilador de
CORBA IDL. O uso de um compilador reduz o número de potenciais
inconsistências entre stubs do cliente e skeletons do servidor e aumenta o
número de oportunidades de optimizações automatizadas do compilador.
?
Invocação Dinâmica do Interface (IDI)– Este interface permite que um
cliente aceda directamente aos mecanismos subjacentes do pedido fornecidos
por um ORB. As aplicações usam o IDI para emitir dinamicamente pedidos
aos objectos sem requerer stubs específicos aos quais iriam ser ligados. Ao
contrário dos stubs de IDL (que permitem apenas pedidos do género do RPC),
o IDI permite também que os clientes façam chamadas síncronas adiadas que
não bloqueiam (operações de envio e recepção separadas), chamadas de
sentido único (apenas envio).
?
Interface Skeleton Dinâmico (ISD) – Este é o análogo ao IDI do lado cliente
para o lado servidor. O ISD permite que um ORB entregue pedidos a uma
implementação do objecto, que não tenha conhecimento em tempo de
91
Bases de Dados Distribuídas
compilação do tipo do objecto que está a executar. O cliente que faz o pedido
não faz ideia de se a implementação está a usar os skeletons específicos ao tipo
do IDL ou se está a usar os skeletons dinâmicos.
?
Adaptador do objecto -- Suporte para o ORB, que entrega os pedidos ao
objecto e activa-o. Mais importante, o adaptador do objecto associa as
implementações ao ORB. Os adaptadores do objecto podem ser especializados
de modo a fornecer o suporte a determinados estilos de implementação do
objecto (tais como adaptadores do objecto OODB para persistência e
adaptadores do objecto de biblioteca para objectos não-remotos).
?
GIOP (General Inter-ORB protocol) – Protocolo Geral Inter-ORB. Especifica
a sintaxe de transferência e um conjunto standard de formatos de mensagens
para a interoperação ORB através de qualquer meio de transporte orientado à
conexão.
?
IIOP (Internet Inter-ORB protocol) – Protocolo Internet Inter-ORB.
Especifica como o GIOP pode ser implementado usando o TCP/IP.
92
Bases de Dados Distribuídas
A2 - COM21
COM refere-se tanto a uma especificação como a uma implementação desenvolvida
pela Microsoft Corporation, que fornece uma estrutura para componentes integrados. Esta
estrutura suporta a interoperabilidade e reutilizabilidade de objectos distribuídos, permitindo
que os programadores construam sistemas através da junção de componentes reutilizáveis
de vendedores diferentes, que comunicam através de COM. Aplicando o COM à construção
de sistemas de componentes pré-existentes, os programadores esperam obter benefícios ao
nível da manutenção e adaptabilidade.
O COM define uma interface de programação de aplicações (API) para permitir a
criação dos componentes, que serão integrados nas aplicações feitas ou para permitir que
diversos componentes interajam. No entanto, para que interajam, os componentes devem
aderir a uma estrutura binária especificada pela Microsoft.
Desde que os componentes
adiram a esta estrutura binária, componentes escritos em linguagens diferentes podem
interoperar.
O COM distribuído é uma extensão ao COM que permite a interacção de
componentes através de uma rede. Enquanto os processos COM puderem funcionar na
mesma máquina, mas em espaços de endereçamento diferentes, a extensão de DCOM
permite que os processos estejam espalhados através da rede. Com o DCOM, componentes
que operam numa variedade das plataformas podem interagir, desde que o DCOM esteja
disponível dentro desse mesmo ambiente.
Pode considerar-se que o COM e o DCOM são uma única tecnologia. Esta fornece
uma variedade de serviços para a interacção de componentes, desde serviços que
promovem a integração de componentes numa única plataforma, até à interacção de
componentes através das redes heterogéneas.
De facto, o COM e as suas extensões
DCOM estão unidas num único runtime. Este fornece o acesso local e remoto.
Enquanto o COM e o DCOM representam a tecnologia "de baixo nível" que permite
que os componentes interajam, o OLE, o ActiveX e o MTS representam serviços de
aplicação de alto nível, construídos com base no COM e DCOM. O OLE, construído com
base no COM, fornece serviços tais como linkagem e embedding de objectos usados na
criação de documentos compostos (documentos gerados a partir de múltiplas ferramentas).
O ActiveX prolonga as potencialidades básicas para permitir que componentes sejam
embebidos em Web sites. O MTS prolonga as potencialidades do COM com serviços para
empresas tais como transacções e segurança. Estes permitem que os Enterprise Information
21
Baseado na informação disponível no site http://www.ccs.neu.edu/home/salzberg/com3560/
93
Bases de Dados Distribuídas
Systems (Sistemas de Informação de Empresas) sejam construídos usando componentes de
COM. COM+ é a evolução de COM.
COM+ integra serviços de MTS e queuing (colocação em fila) de mensagens no
COM, e torna a programação de COM mais fácil através de uma integração mais próxima
com linguagens da Microsoft como Visual Basic, Visual C++, e J++. COM+ adicionará não
somente qualidade aproximada à do MTS em cada objecto COM+, mas esconderá também
algumas das complexidades da codificação de COM.
Detalhes Técnicos
O COM é uma especificação binária de compatibilidade e implementação associada
que permite que os clientes invoquem os serviços fornecidos por componentes compatíveis
com COM (objectos COM). Como se pode ver na figura 1, os serviços implementados pelos
objectos COM são expostos através de um conjunto de interfaces que representam o único
ponto do contacto entre clientes e o objecto.
Figura 24: Cliente a utilizar um objecto COM através de um apontador para um Interface
O COM define uma estrutura binária para o interface entre o cliente e o objecto. Esta
estrutura binária fornece a base para a interoperabilidade entre os componentes de software
escritos em várias linguagens. Desde que o compilador possa reduzir as estruturas das
linguagens para esta representação binária, a linguagem de implementação de clientes e
objectos COM não é importante - o ponto do contacto é a representação binária runtime.
Assim, os objectos COM e os clientes podem ser codificados em qualquer linguagem que
suporte a estrutura binária do COM.
O objecto COM pode suportar qualquer número de interfaces. Um interface fornece
uma colecção agrupada de métodos relacionados. Por exemplo, a figura 2 descreve um
objecto COM que simula um relógio. IClock, IAlarm e ITimer são os interfaces do objecto
relógio. O interface IClock pode fornecer os métodos apropriados (não mostrados) para
permitir ajustar e ler a hora actual. Os interfaces IAlarm e ITimer podem fornecer métodos de
alarme e cronómetro.
94
Bases de Dados Distribuídas
Figura 25: Objecto COM relógio
Os objectos e os interfaces COM são especificados utilizando a Interface Definition
Language (Linguagem de Definição de Interfaces) da Microsoft, uma extensão do standard
do DCE Interface Definition Language. Para evitar colisões de nomes, cada objecto e cada
interface deve ter um identificador único.
Os interfaces são considerados logicamente imutáveis. Uma vez definido, não deve
ser alterado – novos métodos não devem ser adicionados e métodos existentes não devem
ser modificados.
Esta limitação aos interfaces não é forçada, é sim, uma regra que os
programadores de componentes devem seguir. Aderir a esta limitação remove as potenciais
incompatibilidades nas versões – se um interface nunca muda, os clientes que dependem
desta podem confiar nesse conjunto consistente de serviços. Se uma funcionalidade nova
tiver de ser adicionada a um componente, pode ser exposta através de um interface
diferente.
Cada objecto COM é executado dentro de um servidor. Um único servidor pode
suportar múltiplos objectos COM. Como se pode ver na figura 3, há três maneiras de um
cliente aceder aos objectos COM fornecidos por um servidor:
1.
Servidor In-process: O cliente pode ligar-se directamente a uma biblioteca
que contém o servidor. O cliente e o servidor executam no mesmo processo.
Uma comunicação é realizada através de chamadas a funções;
2.
Objecto Proxy Local: O cliente pode aceder a um servidor que está a
executar num processo diferente, mas na mesma máquina, através de um
mecanismo de comunicação inter-processos.
Este mecanismo é, de facto,
uma Remote Procedure Call (RPC) leve.
3.
Objecto Proxy Remoto: O cliente pode aceder um servidor remoto que está a
executar numa outra máquina. A comunicação entre o cliente e o servidor é
realizada através de DCE RPC.
O mecanismo que suporta o acesso aos
servidores remotos é chamado DCOM.
95
Bases de Dados Distribuídas
Figura 26: Três métodos para aceder a objectos COM
Se o cliente e o servidor estiverem no mesmo processo, partilhar os dados entre os
dois é simples. Mas, quando o processo do servidor está separado do processo do cliente,
como num servidor local ou remoto, o COM deve formatar e preparar os dados de modo a
que os possa partilhar. Este processo de preparar os dados é chamado marshalling. O
marshalling é realizado através de um objecto proxy e de um objecto stub que lidam com os
detalhes da comunicação de processos cruzados para qualquer interface (descrita na figura
4). O COM cria o stub no processo do servidor do objecto e manda o stub controlar o
verdadeiro apontador do interface. O COM cria então o proxy no processo do cliente, e liga-o
ao stub. O proxy fornece então o apontador do interface ao cliente.
O cliente chama os interfaces do servidor através do proxy, que faz o marshal dos
parâmetros e passa-os para o stub do servidor. O stub faz o unmarshal dos parâmetros e
realiza a chamada dentro do objecto servidor.
Quando a chamada termina, o stub faz
novamente o marshal dos valores de retorno e passa-os para o proxy, que, por sua vez, os
retorna ao cliente. O mesmo mecanismo de proxy/stub é usado quando o cliente e o servidor
estão em máquinas diferentes. Porém, a implementação interna de marshalling e
unmarshalling difere, dependendo de se o cliente e o servidor operam na mesma máquina
(COM) ou em máquinas diferentes (DCOM).
Dado um ficheiro IDL, o compilador de
Microsoft IDL pode criar o proxy default e o código do stub que executa todo o marshalling e
unmarshalling necessário.
96
Bases de Dados Distribuídas
Todos os objectos COM estão registados numa base de dados de componentes.
Quando um cliente deseja criar e utilizar um objecto COM:
1.
Invoca uma API COM para instanciar um novo objecto COM.
2.
O COM localiza a implementação do objecto e inicia um processo servidor para o
objecto.
3.
O processo do servidor cria o objecto, e retorna um apontador para o interface
do objecto.
4.
O cliente pode então interagir com o objecto COM recentemente instanciado
através do apontador para o interface.
Um aspecto importante no COM é que os objectos não têm identidade, isto é, um
cliente pode pedir um objecto COM de algum tipo, mas não um objecto em particular. De
cada vez que o COM é invocado, para pedir um objecto COM, uma nova instância é
retornada. A vantagem principal desta política reside em que as implementações COM
podem juntar os objectos COM numa pool e retornar estes mesmos objectos aos clientes
que os pediram. Sempre que um cliente terminou de utilizar um objecto, a instância é
devolvida à pool. Porém, existem mecanismos para simular a identidade em COM tais como
monikers.
97
Bases de Dados Distribuídas
A3 - ODBC22
Open Database Connectivity (ODBC)
? É um interface de aplicação proposto pela Microsoft em 1991 para a
construção de aplicações de bases de dados heterogéneas, suportada pela
maioria dos produtos relacionais;
? A linguagem suportada pelo ODBC é apenas o SQL, caracterizado por um
conjunto mínimo de instruções;
? As aplicações interagem com os servidores de SGBD através de um driver
(uma biblioteca dinamicamente ligada às aplicações). O driver esconde as
diferenças de interacção devido ao SGBD, o sistema operativo e o
protocolo de rede. Por exemplo, o trio (Sybase, Windows/NT, Novell)
identifica um driver específico
? O ODBC não suporta o protocolo two-phase commit.
Figura 27 : Arquitectura do ODBC
Componentes do ODBC
? A aplicação lança inquéritos SQL;
? O gestor do driver ODBC carrega os drivers a pedido da aplicação e fornece
funções de conversão de nomes. Este software é fornecido pela Microsoft;
? Os drivers realizam funções ODBC. Executam inquéritos SQL, traduzindo-os,
se necessário, para os adaptar à sintaxe e semântica de produtos específicos;
? A origem de dados é o SGBD remoto, que realiza as funções transmitidas pelo
cliente.
22
Baseado em Paulo Atzeni, Stefano Ceri, Stefano Paraboschi e Ricardo Torlone – Database Systems –
Concepts, Languages and Architectures, McGraw-Hill,
1999
–
livro
disponível
no
site
http://xerox.elet.polimi.it/dbbook/slides.html
98
Bases de Dados Distribuídas
A4 - X Open DTP23
X-Open protocolo distribuído de processamento de transacções (DTP)
? Protocolo que garante a interoperabilidade das transacções em SGBDs de
fornecedores diferentes;
? Assume a existência de um cliente, diversos RMs (Resource Manager –
Gestores de Recursos) e um TM
(Transaction Manager – Gestor da
Transacção);
? O protocolo consiste em duas interfaces:
o Entre o cliente e o TM, chamada interface TM;
o Entre o TM e cada RM, chamada interface XA.
? Os SGBDs relacionais devem fornecer a interface XA.
Vários produtos especializados na gestão de transacções, tal como o Encina
(um produto da Transarc) e o Tuxedo (da Unix Systems, originalmente AT&T)
fornecem o TM.
Características mais importantes do X-Open DTP
? Os RM são passivos; respondem às chamadas remotas a procedimentos
(remote procedure calls) emitidas pelo TM;
? O protocolo utiliza o 2PC com duas optimizações: aborto presumido
apenas leitura;
? O protocolo suporta decisões heurísticas, que na presença de falhas,
permitem a evolução de uma transação sob o controlo do operador
o quando um RM está bloqueado devido a uma falha do TM, um
operador pode impor uma decisão heurística (geralmente o abort),
permitindo assim a libertação de recursos;
o quando as decisões heurísticas causam uma perda de atomicidade, o
protocolo garante que os processos do cliente são notificados;
o a resolução de inconsistências devidas as decisões heurísticas erradas
é dependente da aplicação.
23
Baseado em Paulo Atzeni, Stefano Ceri, Stefano Paraboschi e Ricardo Torlone – Database Systems –
Concepts, Languages and Architectures, McGraw-Hill,
1999
–
livro
disponível
no
site
http://xerox.elet.polimi.it/dbbook/slides.html
99
Bases de Dados Distribuídas
Figura 28: Interacções entre cliente, TM and servidor com o protocolo X-OPEN DTP
Interface TM
? tm_init e tm_exit iniciam e terminam o diálogo entre cliente e TM;
? tm_open e tm_term abrem e fecham a sessão com o TM;
? tm_begin inicia uma transacção;
? tm_commit pede um commit global.
Interface XA
? xa_open e xa_close abrem e fecham a sessão entre o TM e um RM;
? xa_start e xa_end activam e completam uma nova transacção;
? xa_precom pede ao RM para que este realize a primeira fase do protocolo
de commit. O processo RM apenas pode responder positivamente à
chamada se se encontrar num estado recuperável;
? xa_commit e xa_abort comunicam a decisão global acerca da transacção;
? xa_recover inicia o procedimento de recuperação depois da falha de um
processo (TM ou RM); o RM consulta o seu log e constrói três conjuntos de
transacções: transacções em dúvida, transacções decidas por um commit
heurístico e transacções decidas por um abort heurístico.
? xa_forget permite que um RM esqueça as transacções decididas de um
modo heurístico.
100
Bases de Dados Distribuídas
A5 - Regras de Transformação Algébrica24
Legenda :
8 - Join
? - Projecção
? - Selecção
? - União
1.
Comutatividade das operações binárias
R8 S=S8 R
2.
Associatividade das operações binárias
(R 8 S) 8 T = R 8 (S 8 T)
3.
Idempotência
?
x
( ? y (A) ) = ? x (A)
Duas projecções podem ser reduzidas a uma se os atributos da projecção
exterior forem um subconjunto dos atributos da projecção interior.
? x (? y (A)) = ? y (? x (A)) = ? x? y (A)
As selecções são comutativas e podem ser reescritas com AND
4.
Comutatividade da selecção e projecção
A selecção e a projecção podem ser comutadas, desde que, depois da
projecção os atributos da selecção ainda existam
SELECT nome FROM OBRA
WHERE orcamento > 30.000.00
Se for feita primeiro a projecção, temos um problema...
5.
Comutatividade da selecção com operações binárias
? y (A 8 B) = ? y1 (A) 8 ? y2 (B)
24
Baseado em Betty Salzberg, Algorithms for Parallel and Distributed Transaction Systems,
informação disponível no site http://www.ccs.neu.edu/home/salzberg/com3560
101
Bases de Dados Distribuídas
É possível comutar a selecção com operações binárias desde que
? y = y1 AND y2 e
? y1 contenha apenas atributos de A, e y2 contenha apenas atributos de B
(alguns atributos podem estar em A e B).
? y (A ? B) = ? y (A) ? ? y (B)
Porque nas uniões A e B têm os mesmos atributos.
Ex.:
SELECT nome FROM EMPREG
WHERE cargo=1
Supondo que EMPREG está fragmentada em dois fragmentos:
EMPREG1 e EMPREG2.
?
?
cargo=1
?
=
?
EMPREG1
EMPREG2
cargo=1
EMPREG1
?
cargo=1
EMPREG2
Figura 29 : Árvore de Análise Algébrica
6.
Comutatividade da projecção com operações binárias
É possível comutar a projecção com operações binárias. A relação entre
projecções e joins é um pouco complicada.
? y (A 8 z B) = ?
y1
(A) 8 z ?
y2
(B) se
? z está em y1 AND y2 e
? y1 contém apenas atributos de A e
? y2 contém apenas atributos de B e
? y é igual à união de y1 com y2
102
Bases de Dados Distribuídas
Se z não estiver em y:
? y (A 8 z B) = ? y (?
y1,z(A)
8z ?
y2,z(B))
se
? y1 contém apenas atributos de A e
? y2 contém apenas atributos de B e
? y é igual à união de y1 com y2
Ex. :
SELECT nome
FROM EMPREG E, CARGO C
WHERE E.cargo = C.codigo
?
?
nome
8
8
E.cargo = C.codigo
E.cargo = C.codigo
=
?
EMPREG
nome
nome, cargo
?
codigo
CARGO
EMPREG
CARGO
Figura 30: Árvore de Análise Álgébrica
7.
Distributividade de joins sobre uniões
(A 8 B) 8 C ) = (A 8 C )? (B 8 C)
8.
Distributividade de agregações sobre uniões
sumc (A ? B) = sum(cA) + sum(cB)
count (A ? B) = count(A) + count(B)
avgc (A ? B) = _sum(cA) + sum(cB)_
count(A) + count(B)
onde c é a coluna comum a A e B
103