bases de dados distribuídasdei.isep.ipp.pt/~paf/proj/set2002/basesdadosdistribuidas.pdf · um sgbd...

BBaasseess ddee DDaaddooss DDiissttrriibbuuííddaass

PPrroojjeeccttoo ddoo 55ºº AAnnoo ddaa LLiicceenncciiaattuurraa eemm EEnnggeennhhaarriiaa IInnffoorrmmááttiiccaa

RRaammoo ddee CCoommppuuttaaddoorreess ee SSiisstteemmaass

AAnnaabbeellaa ddaa CCoossttaa VViieeiirraa

OOrriieennttaaddoorr:: AAlleexxaannddrree BB rraaggaannççaa

SSeetteemmbbrroo ddee 22000022

Bases de Dados Distribuídas

iii

AAggrraaddeecciimmeennttooss

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.


v

ÍÍnnddiiccee

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 MICROSOFT 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 MEDIADORES...........................................................................................................................73 5. CONCLUSÕES..................................................................................................................................................79

BIBLIOGRAFIA ................................................................................................................................................. 81

GLOSSÁRIO ........................................................................................................................................................ 83

ÍNDICE REMISSIVO........................................................................................................................................ 85


vi

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

ÍÍnnddiiccee ddee FFiigguurraass FIGURA 1 : ORGANIZAÇÃO DE UM SISTEMA DE GESTÃO DE FI CHEIROS ......................................................................5 FIGURA 2 : ORGANIZAÇÃ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 JOIN PARTICIONADO...........................................................................................................31 FIGURA 9 : EXECUÇÃO DE UMA TRANSACÇÃO DISTRIBUÍDA .....................................................................................35 FIGURA 10 : PROTOCOLO 2PC ..................................................................................................................................37 FIGURA 11 : FASES DO TWO-PHASE LOCKING ............................................................................................................40 FIGURA 12 : ÁRVORE DE ANÁLISE ALG ÉBRICA..........................................................................................................45 FIGURA 13 : ÁRVORE DE ANÁLISE ALG ÉBRICA REESTRUTURADA .............................................................................46 FIGURA 14 : OPTIMIZAÇÃ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 OBJECTOS DA RELAÇÃO OBRA-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 CONFLICT 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 UM OBJECTO COM ATRAVÉS DE UM APONTADOR PARA UM INTERFACE............94 FIGURA 25: OBJECTO 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


viii

ÍÍnnddiiccee ddee TTaabbeellaass

TABELA 1 : TABELA EMPREG DA FIRMA DE CONSTRUÇÃO CIVIL .........................................................................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 MATRIZ 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

Introdução

1

11.. IInnttrroodduuççããoo

11..11.. IInnttrroodduuççããoo 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 sub-

mó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


2

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.

11..22.. EEssttrruuttuurraa ddoo RReellaattóórriioo Por razões de lógica e ordem de ideias começaremos por ver conceitos de

Bases de Dados Distribuídas1, 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.

Introdução

3


4


5

22.. BBaasseess ddee DDaaddooss DDiissttrriibbuuííddaass

22..11.. AAnntteecceeddeenntteess ddaass BBaasseess ddee DDaaddooss

DDiissttrriibbuuííddaass 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 ficheiros3

3 M. Tamer Özsu e Patrick Valduriez in Distributed Database Management Systems -

www.csse.monash.edu.au/courseware/cse5200


6

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 Dados4.

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


7

Figura 2 : Organização de uma base de dados6

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).


8

1

2 5 6

8

7 3

4

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 informaçã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.



1

2 5 6

8 3

7

4

CLIENTE

SERVIDOR SERVIDOR

APLICAÇÃO

SERVIDOR

CLIENTE


9

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.

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

LLAADDOO CCLLIIEENN TTEE

LADO SERVIDOR

GESTÃO DO

INTERFACE

GESTÃO DO

INTERFACE

GESTÃO DO

INTERFACE

GESTÃO DO

INTERFACE

GESTÃO DO

INTERFACE

LÓGICA DA

APLICAÇÃO

LÓGICA DA

APLICAÇÃO

LÓGICA DA

APLICAÇÃO

LÓGICA DA

APLICAÇÃO

LÓGICA DA

APLICAÇÃO

LÓGICA DA

APLICAÇÃO

GESTÃO DO

INTERFACE

GESTÃO

DOS DADOS

GESTÃO

DOS DADOS GESTÃO

DOS DADOS GESTÃO

DOS DADOS GESTÃO

DOS DADOS GESTÃO

DOS DADOS

1

2

3

4

5

BASES DE

DADOS

DISTRIBUÍDAS

GESTÃO

REMOTA DE

DADOS

LÓGICA

DISTRIBUÍDA

APRESENTAÇÃO

REMOTA

SISTEMAS

DISTRIBUÍDOS


10

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


11

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.

22..22 DDeeffiinniiççããoo ddee BBaasseess ddee DDaaddooss DDiissttrriibbuuííddaass 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.


12

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


13

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).


14

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


15

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


16

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


17

verificassem as restrições de segurança de todos os dados locais, o que se tornaria

proibitivo em termos de overhead introduzido.

22..33.. RReeggrraass ddee uummaa BBaassee ddee DDaaddooss DDiissttrriibbuuííddaa 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.


18

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.


19

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ó.


20

Nó X

Espera que Espera que

T1 Y acabe T2 X acabe

Nó Y

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

Mantém o lock

do recurso RX

Espera que T1 X liberte RX T1 X T2 X

Espera que T2 Y liberte RY

Mantém o lock

do recurso RY

T1 Y T2 Y


21

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.

22..44.. RReepplliiccaaççããoo ee FFrraaggmmeennttaaççããoo ddee DDaaddooss 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.

Tabela 1 : Tabela EMPREG da firma de Construção Civil

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


22

Tabela 2 : Tabela CARGO

Tabela 3 : Tabela LOCALIZACAO

Tabela 4 : Tabela OBRA

22..44..11.. RReepplliiccaaççããoo ddee DDaaddooss

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;

CODIGO NOME SALARIO

1 mestre-obras € 1500

2 carpinteiro € 1200

3 electricista € 1300

4 servente € 800

CODIGO LOCALIZACAO

1 Porto

2 Lisboa

3 Coimbra

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


23

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


24

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.

22..44..11..11 MMeeccaanniissmmooss ddee aaccttuuaalliizzaaççããoo

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.


25

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


26

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.

22..44..11..22 RReepplliiccaaççããoo ee TToollee rrâânncciiaa aa FFaallhhaass

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.


27

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


28

22..44..22 FFrraaggmmeennttaaççããoo ddee DDaaddooss

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:

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:

Tabela 6 : Fraccionamento Vertical da Tabela de Empregados

CODIGO NOME CARGO

1 F. Rodrigues 4

2 J. Barros 4

3 A. Silva 3

4 J. Sousa 2

5 M. Pereira 1

CODIGO NOME LOCALIZACAO CARGO OBRA

2 J. Barros 2 4 2

5 M. Pereira 2 1 1


29

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:

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.

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.

CODIGO NOME LOCALIZACAO

3 A. Silva 3

CODIGO NOME

1 Lote 2

2 Loja 34


30

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.

22..44..22..11 FFrraaggmmeennttaaççããoo hhoorriizzoonnttaa ll

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.


31

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.


32

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.

22..44..22..22 FFrraaggmmeennttaaççããoo vveerrttiiccaall

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.


33

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

Atributos

Q1 Q2

nome 1 1

Cargo 1 0

Proj 0 1

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


34

22..44..22..33 FFrraaggmmeennttaaççããoo hhííbbrriiddaa

A natureza das aplicações pode exigir uma fragmentação mais complexa. As

técnicas são basicamente as mesmas já apresentadas.

22..44..33.. AAllooccaaççããoo

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


35

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).

22..55 GGeessttããoo ddiissttrriibbuuííddaa ddee ttrraannssaaccççõõeess Segundo M.Tamer Özsu e Patrick Valduriez, uma transacção é uma colecção

de acções que fazem 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ída11




36

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.


37

22..55..11 PPrroottooccoollooss ddee sseegguurraannççaa

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).

22..55..11..11 PPrroottooccoollooss ddee CCOOMMMMIITT

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




38

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.

22..55..11..22 PPrroottooccoollooss ddee AABBOORRTT oouu TTee rrmmiinnaaççããoo

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;


39

- se o coordenador se encontra no estado COMMIT ou ABORT, deve

reenviar a mensagem de COMMIT / ABORT global ao nó em falha.

22..55..11..33 PPrroottooccoollooss ddee RReeccuuppee rraaççããoo

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.

22..55..22 CCoonnttrroolloo ddee CCoonnccoorrrrêênncciiaa

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


40

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 Locking13




41

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.


42

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.

22..66 PPrroocceessssaammeennttoo ddiissttrriibbuuííddoo ddee qquueessttõõeess 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.


43

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


44

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.

22..66..11 PPaassssooss ddoo pprroocceessssaammeennttoo ddiissttrriibbuuííddoo ddee qquueessttõõeess

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.

22..66..11..11 DDeeccoommppoossiiççããoo

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”


45

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.

? nome

? O.orcamento > 30.000.00

? O.localizacao = L.codigo

OBRA ? localizacao = “Porto”

LOCALIZACAO


46

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).

22..66..11..22 LLooccaalliizzaaççããoo

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)

? nome

? O.localizacao = L.codigo

? O.orcamento > 30.000.00 ? localizacao = “Porto”

OBRA LOCALIZACAO


47

O inquérito a considerar: SELECT nome FROM OBRA

WHERE orcamento > 70.000.00

? nome ? nome ? nome

?orcamento ? ?orcamento

= =

?

?orcamento ?orcamento O2

O1 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


48

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.

22..66..11..22 OOppttiimmiizzaaççããoo ddoo iinnqquuéé rriittoo gg lloobbaa ll

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).


49

É 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-joins14.

Para se ter uma ideia mais clara das características destes três algoritmos,

atente-se na tabela abaixo:

Algorit. Função

objectivo

Factores a optimizar Semi-

joins

Estatís-

ticas

Fragmentação

Dist.

INGRE

S

Tempo de respos-

ta ou tempo total

Tamanho das mensagens,

custo do processamento

Não 1 Horizontal

R* Tempo total Nº e tamanho das

mensagens, IO, CPU

Não 1,2 Não

SDD-1 Tempo total Tamanho das mensagens Sim 1,3,4,5 Não

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)


50

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


51

o pedido não é considerado. É baseado no algoritmo Hill Climbing15, 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.

22..77 BBaasseess ddee DDaaddooss DDiissttrriibbuuííddaass MMóóvveeiiss 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.


52

? 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 application-

transparent, onde esta responsabilidade passa a estar do lado do sistema. Como

sempre, a melhor solução reside algures no meio, na chamada adaptação application-

aware, 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.


53

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


54

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


55

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.


56

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.


57

? 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


58

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.

22..88 RReecceenntteess aavvaannççooss nnaa tteeccnnoollooggiiaa ddaass BBDDDD 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.


59

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


60

de standards suficientemente difundidos (a OQL pode ser a solução para este

problema) são duas desvantagens importantes.

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

Objecto

Obra

Objecto

Empregado

OBRA = 1

ORCAMENTO = 300000,00

EMPREGADOS

EMPREGADO = 1

NOME = F.Rodrigues EMPREGADO = 3

NOME = A. Silva

OBRA

next next nil


61

mesma estrutura do SQL (à parte estruturada da informação) e outros inqué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 questõ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


62

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).

Bases de Dados Distribuídas e SQL Server

63

33.. OO MMiiccrroossoofftt SSQQLL SSeerrvveerr

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

(DpropR)

Distributed Relational Database

Arquitecture (DRDA)

DataJoiner

Adaptada à DB2;

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.

BDs heterogéneas.

Middleware para acesso a BDs de outros

fabricantes.

Sybase Replication Server

SQL Anywhere

OmniSQL

Nó primary site e nós read-only distribuídos;

Replicação síncrona;

Replicação hierárquica;

Dados e stored procedures replicados.

BDs móveis.

BDs heterogéneas.

Oracle Table Snapshot Option

Symmetric Replication Option

Snapshots periódicos enviados para os nós

read-only;

Replicação síncrona e assíncrona de qualquer

nó para qualquer outro nó;

Refrescamento diferencial;

Agentes controlam a replicação;

Two-Phase Commit.


64

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.

33..11 RReepplliiccaaççããoo nnoo MMiiccrroossoofftt SSQQLL SSeerrvveerr 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.


65

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


66

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:


67

Autonomia dos nós Consistência Transaccional

Figura 18 : Diferentes Tipos de Replicação em termos de autonomia dos nós e consistência

transaccional18

33..22 FFrraaggmmeennttaaççããoo nnoo MMiiccrroossoofftt SSQQLL SSeerrvveerr 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

Replicação

Merge

Repl. Tran-

saccional

Repl.

Snapshot

Immediate

Updating

Subscriber

Distributed

Transaction

Coordinator


68

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.


69

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.


70

33..33 TTrraannssaaccççõõeess nnoo MMiiccrroossoofftt SSQQLL SSeerrvveerr 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 recursos19 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.


71

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 SQL-

DMO e sua conexão a um servidor com nome “NomeServidor”, login “sa” e

password “ ”: Dim ServerObject As New SQLOLE.SQLServer

ServerObject.Connect “NomeServidor”, “sa”, “ ”

33..44 PPrroocceessssaammeennttoo DDiissttrriibbuuííddoo ddee QQuueessttõõeess nnoo

MMiiccrroossoofftt SSQQLL SSeerrvveerr 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.


72

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 sub-

inqué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.

O caso GIS Mediadores

73

44.. OO ccaassoo GGIISS MMeeddiiaaddoorreess

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,


74

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


75

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


76

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


77

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.

Conclusões

79

55.. CCoonncclluussõõeess 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.


81

BBiibblliiooggrraaffiiaa 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-DistribDB-

4up.pdf


82

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


83

GGlloossssáárriioo

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.


85

ÍÍnnddiiccee RReemmiissssiivvoo

2

2PC (Two-Phase Commit), 37, 38, 39, 64, 70, 87,

99

2PL (Two-Phase Locking), 40, 87

A

Alocação, 2, 21, 34, 41, 43

Arquitectura cliente/servidor, 61

F

Fragmentação, 2, 11, 18, 19, 21, 28, 29, 30, 31, 32,

34, 43, 46, 47, 61, 67, 68, 73

P

Processamento distribuído de questões, 19, 42, 43,

44, 71, 79

R

Replicação, 2, 11, 19, 22, 23, 24, 25, 26, 34, 55, 56,

63, 64, 65, 66, 70, 74, 77, 79

T

Timestamp, 26, 40, 41, 57, 69, 70

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


87

SSiiggllaass

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)


89

AAnneexxooss

AA11 -- CCOORRBBAA2200

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


90

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


91

? 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


92

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.


93

AA22 -- CCOOMM2211

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/


94

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.


95

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.


96

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.


97

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.


98

AA33 -- OODDBBCC2222 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



99

AA44 -- XX OOppeenn DDTTPP2233 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



100

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.


101

AA55 -- RReeggrraass ddee TTrraannssffoorrmmaaççããoo AAllggéébbrriiccaa2244

Legenda : 8 - Join

? - Projecção

? - Selecção

? - União

1. Comutatividade das operações binárias

R 8 S = S 8 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


102

É 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 ?

? =

? cargo=1 ? cargo=1

EMPREG1 EMPREG2 EMPREG1 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


103

Se z não estiver em y:

? y (A 8 z B) = ? y (? y1,z(A) 8 z ? 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

? nome

8 E.cargo = C.codigo

8 E.cargo = C.codigo =

? nome, cargo ? codigo

EMPREG 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

bases de dados distribuídasdei.isep.ipp.pt/~paf/proj/set2002/basesdadosdistribuidas.pdf · um sgbd...

Documents