Banco de Dados Distribuídos

Transcrição

1 Banco de Dados Distribuídos Brasília-DF, 2011.

2 Elaboração: Ednewton de Vasconcelos Produção: Equipe Técnica de Avaliação, Revisão Linguística e Editoração Banco de Dados Distribuídos 2

3 Sumário Apresentação... 4 Organização do Caderno de Estudos e Pesquisa... 5 Organização da Disciplina... 6 Introdução... 8 Unidade I Introdução a Banco de Dados Distribuídos... 9 Capítulo 1 Conceito de Banco de Dados Distribuídos... 9 Capítulo 2 Algumas Questões Preliminares Capítulo 3 Funções Adicionais do Banco de Dados Distribuídos Unidade II Princípio de Banco de Dados Distribuídos Capítulo 4 Fundamentos do Banco de Dados Distribuídos Unidade III Arquitetura e Projeto de Banco de Dados Distribuídos Capítulo 5 Transações Capítulo 6 Tipos de Sistemas BDD Capítulo 7 Problemas de Sistemas Distribuídos Unidade IV Controle, Sincronização e Atualização em Sistemas Distribuídos Capítulo 8 Processamento de Consulta de Sistemas de Diretório e Protocolos de Acesso ao Diretório Para (Não) Finalizar Referências Pós-Graduação a Distância 3

4 Apresentação Caro aluno, Bem-vindo ao estudo da disciplina Banco de Dados Distribuídos. Este é o nosso Caderno de Estudos e Pesquisa, material elaborado com o objetivo de contribuir para a realização e o desenvolvimento de seus estudos, assim como para a ampliação de seus conhecimentos. Para que você se informe sobre o conteúdo a ser estudado nas próximas semanas, conheça os objetivos da disciplina, a organização dos temas e o número aproximado de horas de estudo que devem ser dedicadas a cada unidade. A carga horária desta disciplina é de 40 (quarenta) horas, cabendo a você administrar o tempo conforme a sua disponibilidade. Mas, lembre-se, há uma data-limite para a conclusão do curso, incluindo a apresentação ao seu tutor das atividades avaliativas indicadas. Os conteúdos foram organizados em unidades de estudo, subdivididas em capítulos de forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões para reflexão, que farão parte das atividades avaliativas do curso; serão indicadas também fontes de consulta para aprofundar os estudos com leituras e pesquisas complementares. Desejamos a você um trabalho proveitoso sobre os temas abordados nesta disciplina. Lembre-se de que, apesar de distantes, podemos estar muito próximos. A Coordenação Banco de Dados Distribuídos 4

5 Organização do Caderno de Estudos e Pesquisa Apresentação: Mensagem da Coordenação. Organização da Disciplina: Apresentação dos objetivos e da carga horária das unidades. Introdução: Contextualização do estudo a ser desenvolvido por você na disciplina, indicando a importância desta para sua formação acadêmica. Ícones utilizados no material didático Provocação: Pensamentos inseridos no material didático para provocar a reflexão sobre sua prática e seus sentimentos ao desenvolver os estudos em cada disciplina. Para refletir: Questões inseridas durante o estudo da disciplina, para estimulá-lo a pensar a respeito do assunto proposto. Registre sua visão, sem se preocupar com o conteúdo do texto. O importante é verificar seus conhtecimentos, suas experiências e seus sentimentos. É fundamental que você reflita sobre as questões propostas. Elas são o ponto de partida de nosso trabalho. Textos para leitura complementar: Novos textos, trechos de textos referenciais, conceitos de dicionários, exemplos e sugestões, para lhe apresentar novas visões sobre o tema abordado no texto básico. Sintetizando e enriquecendo nossas informações: Espaço para você fazer uma síntese dos textos e enriquecê-los com sua contribuição pessoal. Sugestão de leituras, filmes, sites e pesquisas: Aprofundamento das discussões. Praticando: Atividades sugeridas, no decorrer das leituras, com o objetivo pedagógico de fortalecer o processo de aprendizagem. Para (Não) finalizar: Texto, ao final do Caderno, com a intenção de instigá-lo a prosseguir com a reflexão. Referências: Bibliografia consultada na elaboração da disciplina. Pós-Graduação a Distância 5

6 Organização da Disciplina Ementa: Introdução aos conceitos de distribuição no contexto das tecnologias de gerência de bases de dados. Aspectos de arquiteturas de sistemas de banco de dados distribuídos. Projeto de bases de dados distribuídas. Apresentação de técnicas envolvidas no processamento distribuído de consultas. Características da gerência de transações. Tendências atuais enfocando os sistemas de banco de dados distribuídos orientados a objetos e os servidores de dados distribuídos. Características de processamento paralelo em sistemas de banco de dados. Algoritmos de processamento paralelo de consultas. Avaliação de desempenho. Análise dos principais sistemas de banco de dados com processamento paralelo. Objetivos: Apresentar as principais metodologias voltadas para a área de desenvolvimento de projetos de banco de dados distribuídos. Conhecer os procedimentos para um entendimento entre os bancos de dados distribuídos e paralelos. Apresentar os mecanismos para a implantação de banco de dados distribuídos. Refletir sobre a gerência, manutenção de banco de dados distribuídos. Elaborar algumas variedades de banco de dados diferentes gerenciados por vários SGBDs. Unidade I Introdução a Banco de Dados Distribuídos Carga horária: 8 horas Conteúdo Capítulo Conceito de Banco de Dados Distribuídos 1 Algumas Questões Preliminares 2 Funções Adicionais do Banco de Dados Distribuídos 3 Unidade II Princípio de Banco de Dados Distribuídos Carga horária: 12 horas Conteúdo Capítulo Fundamentos do Banco de Dados Distribuídos 4 Banco de Dados Distribuídos Unidade III Arquitetura e Projeto de Banco de Dados Distribuídos Carga horária: 15 horas Conteúdo Capítulo Transações 5 Tipos de Sistemas BDD 6 Problemas de Sistemas Distribuídos 7 6

7 Organização da Disciplina Unidade IV Controle, Sincronização e Atualização em Sistemas Distribuídos Carga horária: 5 horas Conteúdo Processamento de Consulta, de Sistemas de Diretório e Protocolos de Acesso ao Diretório Capítulo 8 Pós-Graduação a Distância 7

8 Introdução Imaginação é mais importante que inteligência. Albert Einstein As empresas, os bancos, o comércio, as indústrias e os mais diversos segmentos sociais têm estado muito interessados na descentralização do processamento de suas informações independentemente da localização geográfica de seus escritórios. E com a explosão da Internet ligada aos avanços tecnológicos e aos avanços nas telecomunicações, estas empresas estão cada vez mais propícias a utilizarem Banco de Dados Distribuídos (BDD). A tecnologia de BDD surgiu como uma fusão de duas tecnologias: a de banco de dados e a tecnologia de rede e telecomunicações de dados. Enquanto os primeiros bancos de dados se voltaram para a centralização e resultaram em bancos de dados monolíticos nos anos 1970, logo nas décadas seguintes, o sistema de banco de dados foi-se alterando em pequenas proporções até chegar aos dias de hoje com o avanço de sistemas distribuídos e também decorrente dos sistemas operacionais distribuídos. Ao contrário dos sistemas paralelos, em que os processadores são bastante acoplados e constituem um único sistema de banco de dados, um sistema de banco de dados distribuídos consiste em sites poucos acoplados, que não compartilham componentes físicos. Além do mais, os sistemas de banco que executam em cada site podem ter um grau de independência mútua substancial. Outro fator relevante foi a comunidade de pesquisa de banco de dados ter desenvolvido um trabalho considerável para tratar as questões de distribuição de dados distribuídos e de outros tópicos, bem como ter desenvolvido muitos protótipos de pesquisa. Neste caderno será abordado, o tema banco de Dados Distribuídos, desenvolvimento de tecnologia de banco de dados que está aproximadamente vinculada aos avanços da tecnologia de telecomunicações e de rede. Banco de Dados Distribuídos 8

9 Introdução a Banco de Dados Distribuídos Unidade I Unidade I Introdução a Banco de Dados Distribuídos Se vocês acham que os seus professores são rudes, esperem até terem um chefe. Ele não vai ter pena de vocês. Bill Gates Capítulo 1 Conceito de Banco de Dados Distribuídos Os bancos de dados distribuídos trazem as vantagens da computação distribuída para o domínio do gerenciamento de banco de dados. Um sistema de computação distribuída consiste em vários elementos de processamento, não necessariamente homogêneos, que são interconectados por uma rede de computador e cooperam na execução de certas tarefas. Como uma meta genérica, os sistemas de computação distribuídos dividem um problema grande e intratável em partes menores e os resolvem de maneira eficiente e coordenada. Podemos definir um Banco de Dados Distribuído (BDD) como uma coleção de múltiplos bancos de dados logicamente interrelacionados distribuídos por uma rede de computadores, e um sistema de Gerenciamento de Banco de Dados Distribuídos (SGBD) como um sistema de software que gerencia um banco de dados distribuído enquanto torna a distribuição transparente para o usuário. Uma coleção de arquivos armazenados em nós diferentes de uma rede e a manutenção de inter-relacionamentos entre eles via hiperlinks se tornou uma configuração comum na Internet, com os arquivos Web. As funções comuns de gerenciamento de banco de dados, incluindo o processamento uniforme de consultas e o processamento de transações, não se aplicam, contudo, a esse cenário. Porém, a tecnologia está se modificando em uma direção tal que bancos de dados distribuídos no World Wide Web (WWW) se tornarão uma realidade no futuro próximo. Banco de Dados Homogêneos e Heterogêneos Em um sistema de banco de dados distribuídos homogêneo, todos os sites possuem software de sistema de gerenciamento de banco de dados idêntico, conhecem um ao outro e concordam em cooperar nas solicitações dos usuários do processamento. Neste tipo de sistema, os sites locais entregam uma parte de sua autonomia em termos do seu direito de mudar esquemas ou software de sistema de gerenciamento de banco de dados. Esse software também precisa cooperar com outros sites na troca de informações sobre transações, para tornar o processamento da transação possível entre vários sites. Pós-Graduação a Distância 9

10 Introdução a Banco de Dados Distribuídos Unidade I Ao contrário, em um banco de dados distribuídos heterogêneo, diferentes sites podem usar diferentes esquemas e softwares de sistemas de gerenciamento de banco de dados. Os sites podem não ser cientes um do outro e podem oferecer facilidades apenas limitadas para cooperação no processo da transação. As diferenças nos esquemas normalmente são um problema importante para o processamento da consulta, enquanto a divergência no software se torna um obstáculo para o processamento de transações que acessam múltiplos sites. Arquitetura Cliente/Servidor O objetivo geral desses sistemas é fornecer suporte ao desenvolvimento e à execução de aplicações de banco de dados. Portanto, sob um ponto de vista de mais alto nível, um sistema desse tipo pode ser considerado de estrutura muito simples em duas partes, consistindo em um servidor, também chamado back end, e um conjunto de clientes, chamados front ends. O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBD, definição e manipulação de dados, segurança e integridade de dados, e assim por diante. Em outras palavras, o termo servidor neste contexto é tão somente um outro nome para o SGBD. Os clientes são as diversas aplicações executadas no SGBD, tanto aplicações escritas por usuários quanto aplicações internas. No que se refere ao servidor, não existe diferença alguma entre aplicações escritas pelos usuários e aplicações internas; todas elas empregam a mesma interface para o servidor especificamente, a interface de nível externo. Certas aplicações especiais, chamadas utilitárias, podem constituir uma exceção ao que vimos antes, já que elas às vezes podem ter de operar diretamente no nível interno do sistema. Esses utilitários normalmente são considerados componentes internos do SGBD, em vez de aplicações no sentido mais comum. As aplicações são divididas em dois tipos: aplicações escritas pelo usuário e aplicações fornecidas pelo fabricante. As aplicações escritas pelo usuário são basicamente programadas de aplicação comuns, escritas (em geral) em uma linguagem de programação convencional de terceira geração (L3G), como C++ ou COBOL, ou então em alguma linguagem proprietária de quarta geração (L4G), embora em ambos os casos a linguagem precisa ser, de algum modo, acoplada a uma sublinguagem de dados apropriada. As aplicações fornecidas por fabricante, também conhecidas de ferramentas, são aquelas cuja finalidade básica é auxiliar na criação e execução de outras aplicações. As criadas são aplicações adaptadas a alguma tarefa específica (elas podem não ser muito semelhantes às aplicações no sentido convencional). De fato, a finalidade das ferramentas é permitir aos usuários, em especial aos usuários finais, criar aplicações sem ter de escrever programas em uma linguagem de programação convencional. Por exemplo, uma ferramenta fornecida pelo fabricante será um gerador de relatórios cuja finalidade é permitir que os usuários finais obtenham relatórios formatados a partir do sistema sob requisição. Qualquer requisição de relatórios pode ser considerada um pequeno programa de aplicação, escrito em uma linguagem de geração de relatórios de nível muito alto. Banco de Dados Distribuídos Como o sistema por completo pode estar tão claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em máquinas diferentes. Em outras palavras, existe o potencial para o processamento distribuído. O processamento distribuído significa que máquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicações, de maneira que uma única tarefa de processamento de dados possa ser dividida entre várias máquinas na rede. Na verdade, essa possibilidade é tão atraente por diversos motivos, principalmente de ordem econômica, que o termo cliente/servidor passou a se aplicar quase exclusivamente ao caso em que o cliente e o servidor estão de fato localizados em máquinas diferentes. 10

11 Introdução a Banco de Dados Distribuídos Unidade I Processamento Distribuído A expressão processamento distribuído significa que máquinas diferentes podem estar conectadas entre si em uma rede de comunicações. Um exemplo clássico é a Internet, em que uma única tarefa de processamento de dados possa se estender a várias máquinas na rede. A comunicação entre as várias máquinas é efetuada por algum tipo de software de gerenciamento de rede, possivelmente uma extensão do gerenciador DC ou, mais provavelmente, um componente de software separado. Gerenciador DC Data Communications. As mensagens de comunicação são transmitidas sob o controle de um outro componente de software. O gerenciador não faz parte do SGBD. São possíveis muitos níveis ou variedades de processamento distribuído. Um caso simples envolve a execução do back end do SGBD (o servidor) em uma das máquinas e dos front ends da aplicação (os clientes), conforme a Figura 1. Figura 1 Cliente(s) e servidor funcionando em máquinas diferentes Como exercício de esclarecimento, esboce três exemplos de empresas que utilizem banco de dados distribuídos. Explique em detalhes, conforme a Figura 1. Pós-Graduação a Distância 11

12 Introdução a Banco de Dados Distribuídos Unidade I Como vimos no item Arquitetura Cliente/Servidor, o termo cliente/servidor passou a ser quase sinônimo da disposição ilustrada na Figura 1, na qual o cliente e o servidor funcionam em máquinas diferentes. De fato, há muitos argumentos em favor de um esquema desse tipo: a) o argumento mais comum sobre o processamento paralelo, especificamente, duas ou mais máquinas estão sendo agora aplicadas na tarefa geral, enquanto o processamento do servidor (o banco de dados) e do cliente (a aplicação) está sendo feito em paralelo. Assim, o tempo de resposta e a vazão (throughput) devem ser melhorados; b) além disso, a máquina servidora pode ser uma máquina feita por encomenda para se ajustar à função do SGBD e, assim, fornecer melhor desempenho ao SGBD; c) mesmo assim, a máquina cliente poderia ser uma estação de trabalho pessoal, adaptada às necessidades do usuário final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rápidas e, de modo geral, maiores com facilidade de utilização para o usuário; d) várias máquinas clientes distintas poderiam ser capazes (na verdade, normalmente serão capazes) de obter acesso à máquina servidora. Assim, um único banco de dados poderia ser compartilhado entre vários sistemas clientes distintos, conforme Figura 2. Figura 2 Uma máquina servidora, várias máquinas clientes Banco de Dados Distribuídos Como exercício de esclarecimento, analise a Figura 2 e cite exemplos de instituições que trabalham com esse tipo de serviço de banco de dados. Além dos argumentos anteriores, existe também o fato de que as execuções dos clientes e dos servidores em máquinas diferentes correspondem ao modo como as empresas operam na realidade. É bastante comum que uma única empresa, um banco, por exemplo, opere muitos computadores, de tal modo que os dados correspondentes a uma parte da empresa sejam armazenados em um computador e os dados de outra parte sejam armazenados em outro computador. Prosseguindo 12

13 Introdução a Banco de Dados Distribuídos Unidade I com o exemplo do banco, é muito provável que os usuários de uma agência ocasionalmente tenham de obter acesso a dados armazenados em outra agência. Portanto, observe que as máquinas clientes poderiam ter seus próprios dados armazenados, e a máquina servidora poderia ter suas próprias aplicações. Dessa forma, em geral, cada máquina atuará como um servidor para alguns usuários e como cliente para outros, conforme a Figura 3. Figura 3 Cada máquina pode executar tanto os clientes como o servidor Como exercício de esclarecimetno, analise a Figura 3 tente explicar com suas palavras o qeu você conseguiu entender. O último ponto a mencionar é que uma única máquina cliente poderia ser capaz de obter acesso a várias máquinas servidoras diferentes conforme mostrado na Figura 2. Esse recurso é desejável porque, como já estudamos, as empresas, em geral, operam de tal maneira que a totalidade de seus dados não fica armazenada em uma única máquina, mas se espalha por muitas máquinas distintas, e as aplicações às vezes precisarão ter a capacidade de acessar dados de mais de uma máquina. Basicamente, esse acesso pode ser fornecido de dois modos distintos: a) determinado cliente pode ser capaz de obter acesso a qualquer quantidade de servidores, mas somente um de cada vez, ou seja, cada requisição individual ao banco de dados tem de ser direcionada para apenas um servidor. Em um sistema desse tipo não é possível, dentro de uma única requisição, combinar dados de dois ou mais servidores diferentes. Além disso, o usuário de tal sistema tem de saber qual máquina em particular contém quais partes dos dados; b) O cliente pode ser capaz de obter acesso a vários servidores simultaneamente, isto é, uma única requisição ao banco de dados poderia ter a possibilidade de combinar dados de vários servidores. Nesse caso, os servidores aparentam para o cliente, de um ponto de vista lógico, ser raramente um único servidor, e o usuário não precisa saber qual máquina contém cada uma das partes constituintes dos dados. O item b constitui um exemplo daquilo que se costuma chamar sistema de banco de dados distribuído. Este tema é um grande tópico por si só. Levado a sua conclusão lógica, o suporte completo a bancos de dados distribuídos implica que uma única aplicação deve ser capaz de operar de modo transparente sobre dados espalhados por uma variedade de bancos de dados diferentes, gerenciados por uma variedade de SGBDs diferentes, funcionando em uma variedade de Pós-Graduação a Distância 13

14 Introdução a Banco de Dados Distribuídos Unidade I máquinas distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de comunicações diferentes. Modo transparente significa que a aplicação opera de um ponto de vista lógico, como se os dados fossem todos gerenciados por um único SGBD executado em uma máquina. Banco de Dados Distribuídos 14

15 Introdução a Banco de Dados Distribuídos Unidade I Capítulo 2 Algumas Questões Preliminares Um sistema de banco de dados distribuído consiste em uma coleção de sites, interligados por meio de algum tipo de rede de telecomunicações, em que: a) cada site é por ele próprio, um site completo do sistema de banco de dados; b) os sites concordam em atuar juntos, de modo que um usuário em qualquer site pode ter acesso aos dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site do próprio usuário. Ocorre que o chamado banco de dados distribuído é na verdade uma espécie de banco de dados virtual cujas partes componentes estão fisicamente armazenadas em vários bancos de dados reais distintos em vários sites distintos (com efeito, é a união lógica desses bancos de dados reais). Um exemplo claro é a Figura 4. Figura 4 Um sistema de banco de dados distribuído típico Como exercício de esclarecimento, analise a Figura 4. Se um cliente estiver em Lisboa, poderá acessar as mesmas informações do cliente que está em Brasília? Explique sua resposta. Observe que, repetindo, cada site é um site do sistema de banco de dados por si mesmo. Em outras palavras, cada site possui seus próprios bancos de dados locais reais, seus próprios usuários locais, seu próprio SGBD local e software de gerenciamento de transações, e seu próprio gerenciador de comunicações de dados local (gerenciador DC). Em particular, qualquer usuário pode executar operações sobre dados no seu site local exatamente como se esse site não participasse de modo algum do sistema distribuído. O sistema de banco de dados distribuído em geral pode, portanto, ser considerado Pós-Graduação a Distância 15

16 Introdução a Banco de Dados Distribuídos Unidade I como um tipo de parceria entre SGBD individuais locais nos sites locais individuais; um novo componente de software em cada site uma extensão lógica do SGBD local fornece a funcionalidade necessária à parceria e é a combinação desse novo componente com o SGBD existente, o que constitui aquilo que se costuma chamar sistema de gerenciamento de banco de dados distribuído. Vantagens O gerenciamento de bancos de dados distribuídos tem sido proposto por diversas razões que variam desde a descentralização organizacional e a economia de processamento até a maior autonomia. Destacamos algumas dessas vantagens a seguir: Gerenciamento de dados distribuídos com níveis diferentes de transparência de forma ideal, um SGBD deveria ser transparente na distribuição, no sentido de esconder os detalhes de onde cada arquivo (tabela, relação) está armazenado fisicamente dentro do sistema. Transparência de distribuição ou de rede esta se refere à liberdade para o usuário em relação aos detalhes operacionais da rede. Transparência de replicação cópias dos dados podem ser armazenadas em múltiplos sites para obter melhor disponibilidade, desempenho e confiabilidade. A transparência de replicação faz o usuário não precisar estar ciente da existência das cópias. Transparência de fragmentação existem dois tipos de fragmentação. A fragmentação horizontal distribui uma relação em conjuntos de tuplas (linhas). Exemplo: Se a relação r for fragmentada, r será dividida em uma série de fragmentos r1, r2,..., rn. Esses fragmentos contêm informações suficientes para permitir a reconstrução da relação original r. A fragmentação vertical distribui uma relação em sub-relações, nas quais cada sub-relação é definida por um subconjunto das colunas da relação original. Exemplo: A fragmentação vertical divide a relação decompondo o esquema R da relação r. A fragmentação vertical de r(r) envolve a definição de vários subconjuntos de atributos R1, R2,..., Rn. A fragmentação horizontal normalmente é usada para manter tuplas nos sites em que são mais usados, para minimizar a transferência de dados. Melhoria na confiabilidade e na disponibilidade estas são duas das potenciais vantagens mais comuns citadas para bancos de dados distribuídos. A confiabilidade é definida de maneira ampla como a probabilidade de que um sistema esteja em operação (não seja inoperante) em um determinado momento, ao passo que a disponibilidade é a probabilidade de que o sistema esteja continuamente disponível durante um intervalo de tempo. Quando os dados e o software do SGBD são distribuídos por vários sites, um site pode falhar, então os outros não podem ser acessados. Isso faz aumentar a confiabilidade e a disponibilidade. Uma melhoria é obtida por meio de replicação criteriosa de dados e de software em mais que um site. Em um sistema centralizado, a falha em um dado torna o sistema inteiro indisponível para todos os usuários. Em um banco de dados distribuído, alguns dos dados podem ficar inalcançáveis, mas os usuários ainda podem acessar outras partes do banco de dados. Banco de Dados Distribuídos Melhoria de desempenho um SGBD distribuído fragmenta o banco de dados mantendo os dados mais próximos de onde eles são mais necessários. A localização dos dados reduz a disputa pela CPU e por operações de Entrada/Saída, e simultaneamente reduz os atrasos de acesso envolvidos em redes remotas WAN. Quando um grande banco de dados é distribuído por múltiplos sites, bancos de dados menores existem em cada site. Como resultado, consultas e transações locais que acessam dados em um único site têm um desempenho melhor por causa dos bancos de dados menores locais. Além disso, cada site possui um número menor de transações que são executadas do que se todas as transações fossem submetidas a um único banco de dados centralizados. O paralelismo entre consultas (interqueries) e o paralelismo dentro das consultas (intraqueries) 16

17 Introdução a Banco de Dados Distribuídos Unidade I podem ser obtidos pela execução de múltiplas consultas em diferentes sites, ou pela quebra de uma consulta em diversas subconsultas que são executadas em paralelo. Isso contribui para a melhoria do desempenho. Expansão mais fácil em um ambiente distribuído a expansão do sistema quanto a acréscimo de mais dados, aumento do tamanho dos bancos de dados ou acréscimo de mais processadores é muito mais fácil. Por que bancos de dados distribuídos são desejáveis? A resposta básica a essa pergunta é que normalmente as empresas já são distribuídas, pelo menos logicamente, em divisões, departamentos, grupos de trabalho etc. e, com grande probabilidade, também, fisicamente em fábricas, laboratórios entre outros. Disso decorre que os dados também já estão normalmente distribuídos, porque cada unidade organizacional dentro da empresa necessariamente manterá dados que são relevantes para sua própria operação. O patrimônio total das informações da empresa é, desse modo, disseminado naquilo que às vezes se costuma chamar de ilhas de informações. Um sistema distribuído fornece as pontes necessárias para conectar essas ilhas. Em outras palavras, ele permite que a estrutura do banco de dados reflita a estrutura da empresa. Dados locais podem ser mantidos em instalações locais, às quais eles pertencem logicamente, enquanto dados remotos estão disponíveis para serem acessados quando for necessário. Um exemplo esclarecerá o que foi dito. Suponha que existam apenas dois sites, um em São Paulo e o outro no Rio de Janeiro, e que se trata de um sistema bancário, com dados de contas para as contas de São Paulo armazenadas em São Paulo e dados de contas para as contas do Rio de Janeiro armazenadas no Rio de Janeiro. Então, as vantagens são óbvias: o arranjo distribuído combina eficiência de processamento (os dados são mantidos próximos ao local em que são usados mais frequentemente) com maior facilidade de acesso (é possível ter acesso a uma conta no Rio de Janeiro a partir de São Paulo e vice-versa, por meio da rede de telecomunicações). Fazer com que a estrutura do banco de dados reflita a estrutura da empresa é provavelmente a principal vantagem dos sistemas distribuídos. Pós-Graduação a Distância 17

18 Introdução a Banco de Dados Distribuídos Unidade I Capítulo 3 Funções Adicionais do Banco de Dados Distribuído A distribuição leva a uma maior complexidade no projeto e na implementação do sistema. Para obter as vantagens potenciais listadas no tópico anterior, o software do SGBDD deve ser capaz de prover as seguintes funções, além daquelas de um SGBD centralizado: Rastreamento de dados habilidade para rastrear a distribuição, a fragmentação e a replicação dos dados por meio da ampliação do catálogo do SGBDD. Processamento de consultas distribuídas habilidade para acessar sites remotos e transmitir consultas e dados entre os vários sites por meio de uma rede de comunicação. Gerenciamento de transações distribuídas habilidade para conceber estratégias de execução para consultas e transações que acessam dados de mais de um site, e para sincronizar o acesso aos dados distribuídos e para manter a integridade do banco de dados global. Gerenciamento dos dados replicados habilidade para decidir qual a cópia de um item de dados replicado será acessada e para manter a consistência das cópias de um item de dados replicado. Recuperação de banco de dados distribuído habilidade para recuperar a partir de falhas em um site individual e a partir de novos tipos de falhas como a queda e dos links de comunicação. Segurança as transações distribuídas devem ser executadas com o gerenciamento adequado da segurança dos dados e dos privilégios de autorização/acesso dos usuários. Gerenciamento do diretório (catálogo) distribuído um diretório contém informações (metadados) sobre os dados no banco de dados. O diretório pode ser global para o BDD inteiro ou local para cada site. O posicionamento e a distribuição do diretório são questões de projeto e de política. Essas funções por si só aumentam a complexidade de um SGBDD em relação a um SGBD centralizado. Antes que possamos perceber completamente as vantagens potenciais da distribuição, precisamos encontrar soluções satisfatórias para essas questões e para esses problemas de projeto. A inclusão de toda essa funcionalidade adicional é difícil de ser obtida, e encontrar soluções ótimas é um passo mais avançado. No nível físico de hardware, os seguintes fatores principais distinguem um SGBDD de um sistema centralizado: a) existem múltiplos computadores, chamados sites ou nós; Banco de Dados Distribuídos b) esses sites devem ser conectados por algum tipo de rede de comunicação para transmitir dados e comandos entre sites. Os sites podem estar todos localizados fisicamente próximos, dentro do mesmo prédio ou do grupo de prédios adjacentes e conectados por uma rede local LAN, ou eles podem ser distribuídos geograficamente por grandes distâncias e conectados por uma rede de enlace longo ou por uma rede remota WAN. As redes locais geralmente utilizam cabos, ao passo que as redes de enlace longo utilizam linhas telefônicas ou satélites. Também é possível usar uma combinação dos dois tipos de redes. As redes podem ter topologias diferentes que definem caminhos de comunicação direta entre os sites. O tipo e a topologia de rede utilizados podem ter um efeito significativo no desempenho e, consequentemente, nas estratégias para 18

19 Introdução a Banco de Dados Distribuídos Unidade I o processamento de consultas distribuídas e para o projeto de banco de dados distribuído. Entretanto, para as questões arquitetônicas de alto nível, não importa o tipo de rede utilizado. Apenas é relevante que cada site seja capaz de se comunicar, direta ou indiretamente, com todos os outros sites. Pós-Graduação a Distância 19

20

21 Unidade II Princípio de Banco de Dados Distribuídos Capítulo 4 Fundamentos do Banco de Dados Distribuídos Em um sistema distribuído, usuários devem comportar-se exatamente como se o sistema não fosse distribuído. Todos os problemas dos sistemas distribuídos são, ou deveriam ser, problemas internos ou do nível de implementação; não, problemas externos ou do nível do usuário. O termo usuários no parágrafo anterior refere-se especificamente a usuários finais ou programadores de aplicações que estão executando operações de manipulação de dados. As operações de definição de dados exigirão alguma extensão em um sistema distribuído, por exemplo, para que um usuário (talvez o DBA) no site A possa especificar que determinada RelVar deve ser dividida em fragmentos que serão armazenados nos sites B e C. O fundamento de BDD conduz doze regras, conforme a seguir: 1. Autonomia local 2. Não dependência de um site central 3. Operação contínua 4. Independência de localização 5. Independência de fragmentação 6. Independência de replicação 7. Processamento de consultas distribuído 8. Gerenciamento de transações distribuído 9. Independência do hardware 10. Independência do sistema operacional 11. Independência da rede 12. Independência do SGDB Pós-Graduação a Distância 21

22 Princípio de Banco de Dados Distribuídos Unidade II Entenda que essas regras não são todas independentes umas das outras nem são necessariamente completas nem igualmente significativas (usuários diferentes darão graus diferentes de importância a objetivos diferentes em ambientes diferentes; na verdade, alguns delas podem ser totalmente não aplicáveis em algumas situações). Contudo, as regras são úteis como base para a compreensão da tecnologia distribuída e como uma estrutura para caracterizar a funcionalidade de sistemas distribuídos específicos. É importante distinguir sistemas de bancos de dados distribuídos verdadeiros, generalizados, dos sistemas que apenas fornecem alguma espécie de acesso a dados remotos (é tudo o que os sistemas cliente/servidor realmente fazem). Em um sistema de acesso a dados remotos, o usuário pode ser capaz de operar sobre dados em um site remoto ou mesmo sobre dados em vários sites remotos simultaneamente, mas as emendas aparecem, ou seja, o usuário está definitivamente ciente, em maior ou menor grau, de que os dados são remotos e precisa se comportar de acordo com esse fato. Ao contrário, em um verdadeiro sistema de banco de dados distribuídos, as emendas ficam escondidas. As 12 Regras Autonomia Os sites, em um sistema distribuído, devem ser autônomos. Autonomia local significa que todas as operações em determinado site são controladas por ele mesmo; nenhum site A deve depender de algum outro site B para sua operação ser bem-sucedida (de outra forma, o fato de que o site C esteja inativo poderia significar que o site A não poderia funcionar, mesmo que não houvesse nada de errado como o próprio site A, o que evidentemente seria indesejável). A autonomia local também implica que dados locais são de propriedade e gerenciamento locais, com contabilidade local; todos os dados realmente pertencem a algum banco de dados local, mesmo que sejam acessíveis a partir de outros sites. Assim, questões como segurança, integridade e representação de armazenamento físico de dados locais permanecem sob o controle e a jurisdição do site local. Na verdade, a regra de autonomia local não é completamente realizável; há várias situações em que um determinado site A precisa ceder um certo grau de controle a algum outro site B. O objetivo de autonomia, então, seria mais precisamente enunciado como: os sites devem ser autônomos na maior extensão possível. Não dependência de um site central Autonomia local implica que todos os sites devem ser tratados como iguais. Em particular, portanto, não haverá qualquer dependência de um site mestre central que forneça algum serviço central. Por exemplo: serviços centralizados de processamento de consultas, gerenciamento de transações ou nomeações tais que o sistema inteiro dependa desse site central. Desse modo, essa segunda regra é uma continuação da primeira regra (se a primeira regra for realizada, a segunda virá logo em seguida). Porém, a não dependência de um site central é desejável por si, mesmo que não seja alcançada a completa autonomia local, motivo pelo qual a enunciamos como uma regra separada. Banco de Dados Distribuídos A dependência de um site central seria indesejável pelo menos por estas duas razões: primeiro, esse site central poderia ser um gargalo; segundo, e mais importante, o sistema seria vulnerável se o site central caísse, todo o sistema cairia (o problema do único ponto de falha). 22

23 Princípio de Banco de Dados Distribuídos Unidade II Operação contínua Uma vantagem dos sistemas distribuídos em geral é que eles devem fornecer maior confiabilidade e maior disponibilidade. Assim como foi explicitado no item Vantagens, referenciado no Capítulo 2, a confiabilidade e a disponibilidade são questões preliminares (funções Adicionais de BDD) e tratadas como gerência, mas também são regras claras e precisas para a utilização de BDD. Confiabilidade é a probabilidade de o sistema funcionar sem queda em qualquer momento dado. A confiabilidade é melhor nos sistemas distribuídos porque esses sistemas não seguem a proposta de tudo ou nada. Eles podem continuar a funcionar (em nível reduzido) mesmo diante da falha de algum componente individual, como um site isolado. Disponibilidade é a probabilidade de o sistema estar pronto e funcionando continuamente sem queda durante um período especificado. Assim como a confiabilidade, a disponibilidade é melhor em um sistema distribuído, em parte pela mesma razão, em parte devido à possibilidade de replicação de dados. As discussões anteriores se aplicam ao caso em que uma parada não planejada (isto é, uma falha de algum tipo) ocorreu em algum momento no sistema. As paradas não planejadas são obviamente indesejáveis, mas difíceis de evitar inteiramente. Ao contrário, as paradas planejadas nunca devem ser necessárias; isto é, nunca deve ser preciso desligar o sistema para a execução de alguma tarefa, como adicionar um novo site ou atualizar o SGBD em um site existente para uma nova versão. Sem dúvida, você já deve ter percebido que a independência de localização é somente uma extensão do conceito familiar de independência (física) de dados. Independência de localização A idéia básica da independência de localização (também chamada transparência de localização) é simples: os usuários não devem ser obrigados a saber onde estão fisicamente armazenados os dados, mas devem ser capazes de se comportar pelo menos de um ponto de vista lógico como se os dados estivessem todos armazenados em seu próprio site local. A independência de localização é desejável porque simplifica os programas de aplicações e as atividades do usuário final; em particular, permite que dados migrem de um site para outro sem invalidar qualquer desses programas ou atividades. Essa capacidade de migração é desejável porque permite que dados sejam deslocados pela rede em resposta a alterações de exigências de desempenho. Independência de fragmentação Um sistema admite fragmentação de dados se determinada Relação Variável armazenada pode ser dividida em pedaços ou fragmentos para fins de armazenamento físico, e os fragmentos distintos podem ser armazenados em sites diferentes. A fragmentação é desejável por motivos de desempenho: os dados podem ser armazenados no local em que são utilizados mais frequentemente, de modo que a maior parte das operações seja apenas local, e o tráfego da rede seja reduzido. Por Pós-Graduação a Distância 23

24 Princípio de Banco de Dados Distribuídos Unidade II exemplo: considere o RelVar EMP ( empregados ), com a amostra de valores apresentada na parte superior da Figura 5. Em um sistema que admitisse a fragmentação, poderíamos definir dois fragmentos: FRAGMENT EMP AS S_EMP AT SITE SÃO PAULO WHERE DEPTO# = D1 OR DEPTO# = D3, R_EMP AT SITE RIO DE JANEIRO WHERE DEPTO# = D2 ; Figura 5 Um exemplo de fragmentação Vimos que existem duas espécies de fragmentação, horizontal e vertical, correspondentes às operações relacionais de restrição e projeção, respectivamente. (A Figura 5 ilustra uma fragmentação horizontal). Suponha que tuplas EMP são mapeadas no armazenamento físico de modo bastante direto, e que D1 e D3 são departamentos de São Paulo, e D2 é um departamento do Rio de Janeiro. Tuplas para empregados em São Paulo serão armazenadas no site de São Paulo, e tuplas para empregados no Rio de Janeiro serão armazenadas no site do Rio de Janeiro. Observe na Figura 5 os nomes dos fragmentos internos do sistema, S_EMP e R_EMP. Banco de Dados Distribuídos A reconstrução da RelVar básica original a partir dos fragmentos é feita através de operações de junção e união adequadas (junção para fragmentos verticais, união para fragmentos horizontais). A propósito, no caso de união, observe que a eliminação de duplicatas não será necessária, graças à primeira das duas regras anteriores, ou seja, a união será uma união disjunta. 24

25 Princípio de Banco de Dados Distribuídos Unidade II Se realmente quisermos armazenar o mesmo fragmento de informações em vários lugares diferentes, poderemos fazê-lo por meio do mecanismo de replicação do sistema, a fim de obter o efeito desejado. Devemos nos aprofundar mais um pouco sobre a questão de fragmentação vertical. Visto que tal fragmentação deve ser realizada sem perdas, fica claro que a fragmentação da RelVar EMP da Figura 5 em suas projeções sobre, digamos, {EMP#,DEPTO#} e {SALÁRIO} não seria válida. Contudo, em alguns sistemas, RelVars armazenadas são consideradas como tendo uma ID de tupla, ou atributo TID oculto, fornecido pelo sistema, onde a TID para determinada tupla armazenada é, em linhas gerais, o endereço da tupla em questão. Esse atributo TID é claramente uma chave candidata para a RelVar em questão. Assim, por exemplo, se a RelVar EMP incluísse tal atributo, ela poderia ser fragmentada de modo válido em suas projeções sobre {TID,EMP#,DEPTO#} e {TID,SALÁRIO}, pois essa fragmentação, sem dúvida, seria sem perdas. Observe ainda que o fato de os atributos TID serem ocultos não viola o Princípio da Informação, pois a independência de fragmentação, que discutiremos em seguida, significa que o usuário, de qualquer forma, não está ciente da fragmentação. A propósito, observe que a facilidade de fragmentação e a facilidade de reconstrução são duas das muitas razões pelas quais os sistemas distribuídos são relacionais; o modelo relacional fornece exatamente as operações necessárias para essa tarefa. Agora, chegamos ao ponto mais importante: um sistema que admita fragmentação de dados também deve admitir independência de fragmentação (também conhecida como transparência de fragmentação). Isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados na verdade não estivessem fragmentados de modo algum. A independência de fragmentação (como a independência de localização) é desejável porque simplifica programas do usuário e atividades de terminal. Em particular, ela permite que os dados sejam refragmentados a qualquer momento, e os fragmentos sejam redistribuídos a qualquer momento em resposta a mudanças nas exigências de desempenho, sem invalidar quaisquer desses programas ou atividades do usuário. A independência de fragmentação implica que será apresentada aos usuários uma visão dos dados na qual os fragmentos estão combinados logicamente por meio de junções e uniões adequadas. É responsabilidade do otimizador determinar a quais fragmentos é necessário ter acesso físico para satisfazer a qualquer requisição do usuário. Por exemplo, dada a fragmentação mostrada na Figura 5, se o usuário emitir a requisição: EMP WHERE SALÁRIO > 40K AND DEPTO# = D1 O otimizador saberá, pelas definições do fragmento que estarão armazenadas no catálogo que o resultado inteiro pode ser obtido no site de São Paulo. Não haverá necessidade alguma de acessar o site do Rio de Janeiro. Examinaremos esse exemplo com um pouco mais de detalhe. Em primeiro lugar, a RelVar EMP, tal como é percebida pelo usuário, pode ser considerada (informalmente) uma visão dos fragmentos básicos S_EMP e R_EMP: VAR EMP VIEW S_EMP UNION R_EMP; /*pseudocódigo*/ Assim, o otimizador transforma a requisição original do usuário na seguinte: (S_EMP UNION R_EMP) WHERE SALÁRIO >40, AND DEPTO# = DEPTO# ( D1 ) Pós-Graduação a Distância 25

26 Princípio de Banco de Dados Distribuídos Unidade II Essa expressão pode ainda ser transformada em: (S_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 )) UNION (R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 )) (porque a restrição é distributiva em relação à união). Em seguida, a partir da definição do fragmento R_EMP no catálogo, o otimizador sabe que o segundo desses dois operandos de UNION é equivalente a: EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO# ( D1 ) AND DEPTO# DEPTO# ( D2 ) Essa expressão deverá ser avaliada como uma relação vazia, pois a condição na cláusula WHERE nunca poderá ter o valor TRUE. A consulta original pode então ser simplificada para apenas: R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO ( D1 ) Agora, o otimizador sabe que só precisa ter acesso ao site de São Paulo. Considere o que significa para o otimizador lidar com a requisição: EMP WHERE SALÁRIO > 40K Independência de replicação Um sistema admite replicação de dados se determinada RelVar básica, ou, mais geralmente, determinado fragmento de determinada RelVar básica pode ser representada por muitas cópias ou réplicas distintas, armazenadas em muitos sites distintos. Por exemplo: REPLICATE S EMP AS SR_EMP AT SITE SÃO PAULO ; REPLICATE R EMP AS RS_EMP AT SITE RIO DE JANEIRO ; Banco de Dados Distribuídos Veja a Figura 6. Observe os nomes internos de réplicas do sistema, SR_EMP e RS_EMP. 26

27 Princípio de Banco de Dados Distribuídos Unidade II Figura 6 Um exemplo de replicação A replicação é desejável por ao menos dois motivos. Primeiro, pode significar melhor desempenho (aplicações podem operar sobre cópias locais, em vez de terem de se comunicar com site remotos); segundo, também pode significar melhor disponibilidade (algum objeto replicado permanece disponível para processamento pelo menos para acesso, enquanto houver no mínimo uma cópia disponível). Naturalmente, a maior desvantagem da replicação é que, quando determinado objeto replicado é atualizado, todas as cópias desse objeto precisam ser atualizadas: o problema da propagação de atualizações. Exercício de esclarecimento. Qual é a diferença de independência de fragmentação e independência de replicação? Dê exemplos nos dois casos. Observamos de passagem que a replicação em um sistema distribuído representa uma aplicação específica da ideia de redundância controlada. A replicação, como a fragmentação, deve no caso ideal ser transparente para o usuário. Em outras palavras, um sistema que admita replicação de dados também deve admitir independência de replicação (também conhecida como transparência de replicação), isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados de fato não fossem replicados de modo algum. A independência de replicação (como a independência de localização ou de fragmentação) é desejável porque simplifica os programas de aplicações e as atividades do usuário final; em particular, ela permite que réplicas sejam criadas ou destruídas em qualquer momento, em resposta a mudanças de requisitos, sem invalidar quaisquer um desses programas ou atividades. A independência de replicação implica a responsabilidade do otimizador do sistema de determinar a quais réplicas é necessário atribuir acesso físico para satisfazer qualquer requisição de um determinado usuário. Omitimos aqui os detalhes específicos da questão. Muitos produtos comerciais atuais admitem uma forma de replicação que não inclui a independência de replicação total, ou seja, ela não é totalmente transparente para o usuário. Pós-Graduação a Distância 27

28 Princípio de Banco de Dados Distribuídos Unidade II Processamento de consultas distribuído Há dois aspectos gerais a serem analisados: I. Considere a consulta Obter fornecedores em São Paulo de peças vermelhas. Suponha que o usuário esteja no site do Rio de Janeiro e que os dados estejam armazenados no site de São Paulo. Suponha também que existem n fornecedores que satisfazem à requisição. Se o sistema for relacional, a consulta envolverá basicamente duas mensagens: uma para enviar a requisição de São Paulo para o Rio de Janeiro e outra para retornar o conjunto de resultados de n tuplas do Rio de Janeiro para São Paulo. Se, por outro lado, o sistema não for relacional, mas sim um sistema de um registro por vez, a consulta envolverá basicamente 2n mensagens: n de São Paulo para o Rio de Janeiro solicitando o próximo fornecedor, e n do Rio de Janeiro para São Paulo, a fim de retornar o próximo fornecedor. Assim, o exemplo ilustra o fato de que o sistema distribuído relacional provavelmente irá superar um sistema não relacional em desempenho, possivelmente por várias ordens de grandeza. II. A otimização é ainda mais importante em um sistema distribuído do que em um sistema centralizado. O detalhe é que, em uma consulta como a mencionada no item I, envolvendo diversos sites, haverá muitos modos possíveis de mover os dados pelo sistema de maneira a satisfazer à requisição e é de importância crucial que se encontre uma estratégia eficiente. Por exemplo, uma requisição de união de uma relação ra armazenada no site A e uma relação rb armazenada no site B poderia ser executada movendo-se rb para A ou movendo-se ra para B, ou ainda movendo-se ambas para um terceiro site C etc. Para resumir rapidamente o exemplo, são analisadas seis diferentes estratégias para processamento da consulta sob um certo conjunto de hipóteses plausíveis, e o tempo de resposta varia de um mínimo de um décimo de segundo a um máximo de aproximadamente seis horas. Portanto, a otimização é claramente crucial e esse fato, por sua vez, pode ser visto como mais uma razão pela qual os sistemas distribuídos são sempre relacionais (observando-se que as requisições relacionais podem ser otimizadas enquanto as requisições não relacionais não podem). Analise, com calma, os itens I e II e explique a principal diferença entre eles. Gerenciamento de transações distribuído Banco de Dados Distribuídos Existem dois aspectos principais do gerenciamento de transações: recuperação e concorrência. Cada um deles exige um extenso tratamento no ambiente distribuído. Para explicar esse extenso tratamento, é preciso antes introduzir um novo termo, agente. Em um sistema distribuído, uma única transação pode envolver a execução de código de vários sites; em particular, pode envolver atualizações em muitos sites. Dizemos então que cada transação consiste em vários agentes, em que um agente é o processo executado em favor de determinada transação em um site específico. E o sistema precisa saber quando dois agentes são ambos da mesma transação. Por exemplo: dois agentes que fazem parte da mesma transação obviamente não podem ter um impasse (deadlock) entre eles. Passando agora especificamente à recuperação: para garantir que determinada transação é atômica (tudo ou nada) no ambiente distribuído, o sistema deve, portanto, assegurar que o conjunto de agentes para essa transação tenha feito o commit em uníssono ou o roll back em uníssono. Esse efeito pode ser obtido por meio de protocolo de COMMIT em duas fases. 28

29 Princípio de Banco de Dados Distribuídos Unidade II Independência do hardware Na verdade, não há muito a dizer sobre esse assunto, pois o título já diz tudo. Instalações de computadores do mundo real, em geral, envolvem uma multiplicidade de máquinas diferentes, (máquinas IBM, máquinas Fujitsu, máquinas HP, PCs e estações de trabalho de várias espécie). E existe uma necessidade real de ser capaz de integrar os dados em todos esses sistemas e apresentar ao usuário uma imagem de um único sistema. Assim, é desejável poder executar o mesmo SGBD em diferentes plataformas de hardware e, ainda mais, ter todas essas máquinas diferentes participando como parcerias em um sistema distribuído. Independência do sistema operacional Esse objetivo é, em parte, uma sequência do item anterior e também não exige muita discussão aqui. Obviamente, é desejável não apenas poder executar o mesmo SGBD em diferentes plataformas de hardware, mas também poder executálo em diferentes plataformas de sistemas operacionais, inclusive sistemas operacionais distintos no mesmo hardware. Por exemplo: fazer uma versão OS/390, uma versão UNIX e uma versão Windows participarem todas do mesmo sistema distribuído. Independência da rede Mais uma vez, não há muito a dizer. Se o sistema deve ser capaz de admitir muitos sites diferentes, com diferentes tipos de hardware e sistemas operacionais distintos, é evidente que ele precise admitir diversas redes de telecomunicações distintas. Independência do SGBD Consideramos o que está envolvido na ação de relaxar a hipótese de homogeneidade estrita. Podemos afirmar que essa hipótese é um pouco forte. É necessário apenas que as instâncias do SGBD em sites diferentes admitam todas a mesma interface, elas não precisam ser todas necessariamente cópias do mesmo software de SGBD. Pós-Graduação a Distância 29

30

31 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Capítulo 5 Transações Normalmente, uma coleção de várias operações sobre o banco de dados parece ser uma única entidade do ponto de vista do usuário do banco de dados. Por exemplo: uma transferência de fundos de uma conta corrente para uma conta poupança é uma única operação do ponto de vista do cliente, contudo, dentro do sistema de banco de dados, ela consiste em várias operações. Logicamente, é essencial que todas essas operações ocorram ou que, no caso de uma falha, nenhuma delas ocorra. Seria inaceitável se a conta corrente fosse debitada, mas a conta poupança não fosse creditada. Coleções de operações que formam uma única unidade lógica de trabalho são chamadas transações. Um sistema de banco de dados precisa garantir a execução apropriada de transações apesar das falhas, ou a transação inteira é executada, ou nenhuma parte dela é executada. Além do mais, ele precisa gerenciar a execução simultânea de transações de modo a evitar a introdução da inconsistência. Em nosso exemplo de transferência de fundos, uma que calcula calculando o valor total do cliente poderia ver o saldo da conta corrente antes de ser debitado pela transação de transferência de fundos, mas ver o saldo da poupança depois de ser creditado. Como resultado, ela obteria um resultado incorreto. Conceito de transação Uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários itens de dados. Normalmente, uma transação é iniciada por um programa do usuário escrito em uma linguagem de manipulação de dados ou linguagem de programação de alto nível, por exemplo, SQL, C++ ou Java, em que é delimitada pelas instruções (ou chamadas de função) na forma Begin transaction e end transaction. A transação consiste em todas as operações executadas entre o Begin transaction e o end transaction. Para garantir a integridade dos dados, é necessário que o sistema de banco de dados mantenha as seguintes propriedades das transações: a) Atomicidade todas as operações da transação são refletidas corretamente no banco de dados, ou nenhuma delas. b) Consistência a execução de uma transação isolada, ou seja, sem qualquer outra transação executando simultaneamente, preserva a consistência do banco de dados. c) Isolamento embora várias transações possam ser executadas simultaneamente, o sistema garante que, para cada par de transações Ti e Tj, parece para Ti que ou Tj terminou a execução antes que Ti começasse, ou Tj iniciou a execução depois que Ti terminou. Assim, cada transação não está ciente das outras transações executando simultaneamente no sistema. Pós-Graduação a Distância 31

32 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III d) Durabilidade depois que uma transação for completada com sucesso, as mudanças que ela fez ao banco de dados persistem, mesmo que existam falhas no sistema. Essas propriedades normalmente são conhecidas como propriedades ACID; o acrônimo é derivado da primeira letra de cada uma das quatro propriedades. Para entender melhor as propriedades ACID e a necessidade delas, considere um sistema bancário simplificado, consistindo em várias contas e um conjunto de transações que acessem e atualizem essas contas. Por enquanto, vamos supor que o banco de dados resida permanentemente no disco, mas que alguma parte dele esteja residindo temporariamente na memória principal. As transações acessam dados usando duas operações: I. read(x), que transfere o item de dados X do banco de dados para um buffer local pertencente à transação que executou a operação read; II. write(x), que transfere o item de dados X do buffer local da transação que executou o write de volta ao banco de dados. Em um sistema de banco de dados real, a operação write não necessariamente resulta na atualização imediata dos dados no disco; a operação write pode ser armazenada temporariamente na memória e executada no disco mais tarde. Por enquanto, porém, vamos supor que a operação write atualize o banco de dados imediatamente. Suponha que Ti$ seja uma transação que transfere $50 da conta A para a conta B. Essa transação pode ser definida como: TI : read(a); A := A 50; Write(A); Read(b); B := B + 50; Write(B). Agora, vamos considerar cada uma das propriedades ACID. (Para facilitar a apresentação, consideramos as propriedades em uma ordem diferente da ordem A-C-I-D). Banco de Dados Distribuídos Consistência: o requisito de consistência aqui é que a soma de A e B seja inalterada pela execução da transação. Sem o requisito de consistência, o dinheiro poderia ser criado ou destruído pela transação. Podemos verificar facilmente que, se o banco de dados estiver consistente antes de uma execução da transação, ele permanecerá consistente após a execução da transação. Garantir a consistência para uma transação individual é responsabilidade do programador de aplicação que codifica a transação. Atomicidade: suponha que, imediatamente antes da execução da transação Ti, os valores das contas A e B sejam $1.000 e $2.000, respectivamente. Agora suponha que, durante a execução da transação Ti, aconteça uma falha que impede Ti de completar sua execução com sucesso. Os exemplos dessas falhas incluem falta de 32

33 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III energia, falha de hardware e erros de software. Além disso suponha que a falha aconteceu depois da operação write(a), mas antes da operação write(b). Nesse caso, os valores das contas A e B refletidos no banco de dados são $950 e $2000. O sistema destruiu $50 como resultado dessa falha. Em particular, notamos que a soma A + B não é mais preservada. Assim, devido à falha, o estado do sistema não reflete mais um estado real do mundo que o banco de dados deveria capturar. Chamamos esse estado de estado inconsistente. Temos de garantir que essas inconsistências não sejam visíveis em um sistema de banco de dados. Observe, porém, que o sistema precisa, em algum ponto, estar em um estado inconsistente. Mesmo que a transação Ti seja executada até o término, existe um ponto em que o valor da conta A é $950 e o valor da conta B é $2.000, o que claramente é um estado inconsistente. Porém, esse estado por fim será substituído pelo estado consistente, em que o valor da conta A é $950 e o valor da conta B é $ Assim, se a transação nunca foi iniciada ou foi completada com sucesso, esse estado inconsistente não seria visível, exceto durante a execução da transação, ou seja, o motivo para o requisito de atomicidade. Se a propriedade de atomicidade estiver presente, todas as transações são refletidas no banco de dados, ou nenhuma delas. A ideia básica por trás da garantia da atomicidade é esta: o sistema de banco de dados acompanha (em disco) os valores antigos de quaisquer dados em que uma transação realiza uma escrita e, se a transação não completa sua execução, o sistema de banco de dados restaura os valores antigos para que apareçam como se a transação nunca tivesse sido executada. Durabilidade: quando a execução da transação termina com sucesso, e o usuário que iniciou a transação foi notificado de que a transferência de fundos aconteceu, é preciso que nenhuma falha no sistema resulte em perda dos dados correspondentes a essa transferência de fundos. A propriedade de durabilidade garante que, quando uma transação é executada com sucesso, todas as atualizações que ela executou no banco de dados persistem, mesmo que haja uma falha no sistema após a transação terminar sua execução. Consideramos por enquanto que uma falha do sistema de computador pode resultar na perda de dados na memória principal, mas os dados gravados em disco nunca são perdidos. Podemos conseguir a durabilidade garantindo que: 1. as atualizações executadas pela transação sejam gravadas em disco antes que a transação termine; 2. as informações sobre as atualizações executadas pela transação e gravadas em disco sejam suficientes para permitir que o banco de dados reconstrua as atualizações quando o sistema de banco de dados for reiniciado após a falha. Garantir a durabilidade é responsabilidade de um componente de software do sistema de banco de dados, chamado componente de gerenciamento de recuperação. O componente de gerenciamento de transação e o componente de gerenciamento de recuperação estão bastante relacionados. Isolamento: mesmo que as propriedades de consistência e atomicidade sejam garantidas para cada transação, se várias transações forem executadas simultaneamente, suas operações podem intercalar de alguma maneira indesejável, resultando em um estado inconsistente. Por exemplo, como já vimos, o banco de dados está temporariamente inconsistente enquanto a transação para transferir fundos de A para B está executando, com o total deduzindo gravado em A e o total aumentado ainda a ser gravado em B. Se uma segunda transação executada simultaneamente lê A e B nesse ponto intermediário e calcula A + B, ela observará um valor inconsistente. Além do mais, se essa segunda transação realizar atualizações sobre A e B com base nos valores inconsistentes que ela lê, o banco de dados pode ser deixado em um estado inconsistente mesmo depois que as transações tenham terminado. Pós-Graduação a Distância 33

34 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Um modo de evitar o problema de transações executada simultaneamente é executar transações de modo serial, ou seja, uma após outra. Porém, a execução simultânea de transações oferece benefícios de desempenho significativos. Portanto, outras soluções foram desenvolvidas; elas permitem que várias transações sejam executadas simultaneamente. A propriedade de isolamento de uma transação garante que a execução simultânea das transações resulte em um estado do sistema equivalente ao estado que poderia ter sido obtido se essas transações fossem executadas uma de cada vez em alguma ordem. A garantia da propriedade de isolamento é responsabilidade de um componente do sistema de banco de dados chamado componente de controle de concorrência. Estado da transação Na ausência de falhas, todas as transações são completadas com sucesso. Porém, como observamos anteriormente, uma transação nem sempre pode completar sua execução com sucesso. Essa transação é considerada abortada. Se tivermos de garantir a propriedade de atomicidade, uma transação abortada não pode ter efeito sobre o estado do banco de dados. Assim, quaisquer mudanças que a transação abortada fez no banco de dados precisam ser desfeitas. Quando as mudanças causadas por uma transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida. É parte da responsabilidade do esquema de recuperação gerenciar transações revertidas. Uma transação que completa sua execução com sucesso é considerada confirmada. Uma transação confirmada que realizou atualizações transforma o banco de dados em um novo estado consistente, que precisa persistir mesmo que haja uma falha no sistema. Quando uma transação tiver sido confirmada, não podemos desfazer seus efeitos abortando-a. A única maneira de desfazer os efeitos de uma transação confirmada é executar uma transação de compensação. Precisamos ser mais precisos a respeito do que significa término bem-sucedido de uma transação. Portanto, vamos estabelecer um modelo abstrato simples de transação. Uma transação precisa estar em um dos seguintes estados: ativa, o estado inicial, a transação permanece nesse estado enquanto está executando; parcialmente confirmada, depois que a instrução final foi executada; falha, depois da descoberta de que a execução normal não pode mais prosseguir; abortada, depois que a transação foi revertida e o banco de dados foi restaurado ao seu estado anterior ao início da transação; confirmada, após o término bem-sucedido. Banco de Dados Distribuídos O diagrama de estado corresponde a uma transação conforme, na Figura 7. Dizemos que uma transação foi confirmada somente se ela entrou no estado confirmado. De modo semelhante, dizemos que uma transação foi abortada somente se ela entrou no estado abortado. Uma transação é considerada como terminada se tiver sido confirmada ou abortada. 34

35 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III parcialmente confirmada confirmada ativa falha abortada Figura 7 Diagrama de estado de uma transação Uma transação começa no estado ativo. Quando ela termina sua última instrução, entra no estado parcialmente confirmado. Nesse ponto, a transação completou sua execução, mas ainda pode ser abortada, pois a saída real ainda pode estar temporariamente residindo na memória principal, por isso uma falha de hardware pode impedir seu término bem-sucedido. Pós-Graduação a Distância 35

36 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Capítulo 6 Tipos de Sistemas BDD O termo sistema de gerenciamento de banco de dados distribuído pode descrever vários sistemas que diferem uns dos outros em muitos aspectos. A característica principal que todos os sistemas desse tipo possuem em comum é o fato de que os dados e o software são distribuídos por múltiplos sites conectados por alguma forma de rede de telecomunicações. O primeiro fator que consideramos é o grau de homogeneidade do software do SGBDD. Se todos os servidores, ou SGBDs locais individuais, usam um software idêntico e todos os usuários, clientes, usam um software idêntico, o SGBDD é chamado homogêneo; caso contrário, é chamado heterogêneo. Um outro fator relacionado ao grau de homogeneidade é o grau de autonomia local. Se não há nenhuma provisão para o site local funcionar como um SGBD stand-alone, então o sistema não possui autonomia local. Por outro lado, se for permitido o acesso direto ao servidor para as transações locais, o sistema possui algum grau de autonomia local. Em um extremo do espectro de autonomia, temos um SGBDD que se parece com um SGBD centralizado para o usuário. Existe um único esquema conceitual, e todos os acessos ao sistema ocorrem por meio de um site, que é parte do SGBDD, o que significa que nenhuma autonomia local existe. No outro extremo, encontramos um tipo de SGDBB chamado federado (ou de sistema de multibases de dados). Nesse tipo de sistema, cada servidor é um SGBD centralizado independente e autônomo que tem seus próprios usuários locais, transações locais e DBA e, consequentemente, possui um grau muito alto de autonomia local. O termo sistema de banco de dados federado (SBDF) é usado quando existir alguma visão ou esquema global da federação de banco de dados que é compartilhada pelas aplicações. Por outro lado, um sistema de multibases de dados (multidatabase) não possui um esquema global e constrói interativamente um esquema, conforme a necessidade da aplicação. Ambos os sistemas são híbridos entre os sistemas distribuídos e centralizados, e a distinção que fizemos entre eles não é seguida estritamente. Faremos referências a eles como SBDFs em um sentido genérico. Em um SBDF heterogêneo, um servidor pode ser um SGBD relacional; um outro, um SGBD de rede; e um terceiro SGBD orientado por objeto ou hierárquico. Em tal caso, é necessário possuir uma linguagem de sistema canônica e incluir tradutores da linguagem para traduzir as subconsultas da linguagem canônica para a linguagem de cada servidor. Gerenciamento de SBDF Banco de Dados Distribuídos Diferenças nos modelos de dados: os bancos de dados em uma organização vêm de uma variedade de modelos de dados, inclusive dos, assim chamados, modelos legados (de rede e hierárquico), do modelo de dados relacional, do modelo de dados orientado por objeto, e até mesmo de arquivos. As capacidades de modelagem dos modelos variam. Consequentemente, lidar com eles de maneira uniforme por meio de um único esquema global ou processá-los em uma linguagem única é desafiante. Mesmo se dois bancos de dados forem ambos do ambiente de SGBDR, a mesma informação poderia ser representada com diferentes nomes de atributo, nome de relação ou valores em diferentes bancos de dados. Isso exige um mecanismo inteligente de processamento de consultas que possa relacionar a informação baseando-se nos metadados. Diferenças em restrições: as facilidades de restrições para a especificação e a implementação variam de sistema para sistema. Existem características comparáveis que devem ser reconciliadas na construção de um esquema global. Por exemplo, os relacionamentos dos modelos ER são representados como restrições de integridade referencial no modelo relacional. Gatilhos podem precisar ser usados para implementar certas restrições no modelo relacional. O esquema global também deve tratar dos conflitos potenciais entre as restrições. 36

37 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Diferenças nas linguagens de consulta: Mesmo com o modelo de dados igual, as linguagens e suas versões variam. Por exemplo, o SQL possui múltiplas versões como o SQL-89, o SQL-92 e o SQL-99, e cada sistema possui seu próprio conjunto de tipos de dados, de operadores de comparação, de características de manipulação, de cadeias de caracteres etc. Diferenças no significado As diferenças no significado ou heterogeneidade semântica ocorre quando existem diferenças na interpretação e na intenção de uso dos mesmos dados ou de dados relacionados. A heterogeneidade semântica entre sistemas de banco de dados (SBDs) componentes cria o maior obstáculo no projeto de esquemas globais de banco de dados heterogêneos. A autonomia de projeto de componentes de SBDs refere-se à sua liberdade de escolher os seguintes parâmetros de projeto, que, por sua vez, afetam a complexidade eventual do SBDF: o universo de discurso a partir do qual os dados são retirados por exemplo, duas contas de clientes, banco de dados na federação, podem ser do Brasil e do Japão com conjuntos de atributos completamente diferentes sobre contas de clientes necessárias para as atividades de contabilidade. As flutuações da taxa de câmbio também apresentariam um problema. Consequentemente, as relações nesses dois bancos de dados que possuem nomes idênticos, CLIENTE ou CONTA, podem possuir algumas informações em comum e algumas informações completamente distintas; representação e nomenclatura a representação e a nomenclatura dos elementos de dados e a estrutura do modelo de dados podem ser pré-especificadas para cada banco de dados local; a compreensão, significado e interpretação subjetiva dos dados este é um contribuinte principal para a heterogeneidade semântica; política de transações e de restrições estas tratam do critério de serialização, da compensação de transações e de outras políticas de transações; derivação de sumários agregação, sumarização e outras características de processamento de dados e de operações que têm o suporte do sistema. A autonomia de comunicação de um SBD componente refere-se à sua habilidade em decidir se há comunicações com outro SBD componente. A autonomia de execução refere-se à habilidade de um SBD componente em executar operações locais sem a interferência de operações externas por outros SBDs componentes e à sua habilidade em decidir se e quanto compartilhar de sua funcionalidade (as operações que ele fornece suporte) e de seus recursos (dados que ele gerencia) com outros SBDs componentes. O desafio principal do projeto de SBDFs é fazer os SBDs componentes interoperarem enquanto ainda lhes são proporcionados os tipos de autonomia acima. Uma típica arquitetura de esquema e cinco níveis para fornecer suporte a aplicações globais no ambiente de SBDF são mostradas na Figura 8. Nessa arquitetura, o esquema local é o esquema conceitual (definição completa de banco de dados) de um banco de dados componente, e o esquema do componente é derivado por meio da tradução do esquema local em um modelo de dados canônico ou em um modelo comum de dados (CDM Common Data Model) para o SBDF. A tradução do esquema a partir do esquema local para o esquema do componente é acompanhada pela geração de mapeamentos para transformar os comandos, em um esquema de componente, em comandos no esquema local correspondente. Pós-Graduação a Distância 37

38 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Figura 8 Arquitetura de esquema de cinco níveis em um sistema de banco de dados (SBDF) Fonte: Adaptado de Sheth e Larson, Federated Database Systems for Managing Distribuited Heterogeneous Autonomous Databases. ACM Computing Surveys. v. 22, n. 3, setembro de O esquema de exportação representa o subconjunto de um esquema de componente que está disponível para o SBDF. O esquema federado é o esquema ou visão global, resultado da integração de todos os esquemas de exportação compartilháveis. O esquema externo define o esquema para um grupo de usuários ou para uma aplicação como na arquitetura de esquema de três níveis. Para uma discussão detalhada das autonomias e da arquitetura de cinco níveis dos SGBDFs, consulte Sheth e Larson (1990). Banco de Dados Distribuídos 38

39 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Capítulo 7 Problemas de Sistemas Distribuídos Vamos aprofundar um pouco a discussão sobre alguns dos problemas mencionados anteriormente. O problema principal é que as redes de telecomunicações, pelo menos as redes remotas WANs, são lentas. Uma WAN típica poderia ter uma taxa de dados efetiva de cerca de 5 mil a 10 mil bytes por segundo; ao contrário, uma unidade de disco típica tem uma taxa de dados de cerca de 5 a 10 milhões de bytes por segundo. Por outro lado, algumas redes locais admitem taxas de dados da mesma ordem de grandeza que as unidades de discos. Deste modo, um objetivo essencial nos sistemas distribuídos (pelo menos no caso de WANs e, até certo ponto, também no caso de LANs) é minimizar a utilização da rede, isto é, minimizar o número e o volume de mensagens. Esse objetivo, por sua vez, gera problemas em várias outras áreas, entre elas as seguintes (esta lista não pretende ser completa): Processamento de consultas. Gerenciamento de catálogo. Propagação de atualizações. Recuperação. Concorrência. Processamento de Consultas O objetivo de minimizar a utilização da rede implica que o próprio processo de otimização de consultas precisa ser distribuído, como também o processo de execução de consultas. Em outras palavras, o processo geral de otimização consistirá normalmente em uma etapa de otimização global, seguida por etapas de otimização global, seguida por etapas de otimização local em cada site afetado. Por exemplo, suponha que uma consulta Q seja apresentada no site X, e suponha que Q envolva uma junção de uma relação ry de 10 tuplas no site Y com uma relação rz de 10 milhões de tuplas no site Z. O otimizador do site X escolherá a estratégia global para executar Q; e logicamente é desejável que ele decida mover ry para Z, e não rz para Y (ou, dependendo da cardinalidade do resultado da junção, poderia ser melhor mover ry e rz para X). Suponha que ele decida mover ry para Z. Em seguida, a estratégia para executar a junção real no site Z será decidida pelo otimizador local em Z. Apresentamos, a seguir, uma ilustração mais detalhada do que foi dito. Banco de dados (Fornecedores e peças, simplificado): F {F#, CIDADE } tuplas armazenadas no site A P {P#, COR } tuplas armazenadas no site B FP {F#, P# } tuplas armazenadas no site A Suponha que toda tupla armazenada tenha 25 bytes (200 bits) de extensão. Consulta ( Obter números de fornecedores para fornecedores em Londres de peças vermelhas ): ( ( F JOIN FP JOIN P ) WHERE CIDADE = Londres AND COR = COR ( Vermelho ) ) { F#} Pós-Graduação a Distância 39

40 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Cardinalidade estimadas de certos resultados intermediários: Número de peças vermelhas = 10 Número de remessas por fornecedores de Londres = Hipóteses de comunicações: Taxa de dados = bits por segundo Retardo de acesso = 0,1 segundo Examinamos agora rapidamente seis estratégias possíveis para processar essa consulta, e para cada estratégia i calculamos o tempo de comunicação total Ti a partir da fórmula: ( retardo de acesso total ) + ( volume de dados total / taxa de dados ) Que se torna (em segundos): ( número de mensagens / 10 ) + ( numero de bits / 50000) 1. Mover peças para o site A e processar a consulta em A. T1 = 0,1 + ( * 200 ) / = 400 segundos aprox. (6,67 minutos) 2. Mover fornecedores e remessas para o site B e processar a consulta em B: T2 = 0,2 + ( ( ) * 200 ) / = 400 segundos aprox. (1.12 horas) 3. Fazer a junção de fornecedores e remessas no site A, restringir o resultado a fornecedores de Londres e, em seguida, para cada um desses fornecedores, verificar no site B se a peça correspondente é vermelha. Cada uma dessas verificações envolverá duas mensagens, uma consulta e uma resposta. O tempo de transmissão para essas mensagens será pequeno comparado com o retardo de acesso. T3 = segundos aprox. (5,56 horas) 4. Restringir peças no site B às que são vermelhas, e depois, para cada uma dessas peças, verificar no site A se existe uma remessa relacionando a peça a um fornecedor de Londres. Cada uma dessas verificações envolverá duas mensagens; novamente, o tempo de transmissão para essas mensagens será pequeno comparado com o retardo de acesso. T4 = 2 segundos aprox. Banco de Dados Distribuídos Fazer a junção de fornecedores e remessas no site A, restringir o resultado a fornecedores em Londres, projetar o resultado sobre F# e P# e mover o resultado para o site B. Completar o processamento no site B. T5 = 0,1 + ( * 200 ) / = 400 segundos aprox. (6.67 minutos) 6. Restringir peças no site B às que são vermelhas e mover o resultado para o site A. Completar o processamento no site A. Algumas estratégias permitem processamento paralelo nos dois sites; assim, o tempo de resposta para o usuário poderia na verdade ser menor que em um sistema centralizado. Porém, observe que ignoramos a questão de qual site deve receber o resultado final.

41 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Gerenciamento de catálogo Em um sistema distribuído, o catálogo do sistema incluirá não apenas os dados normais de catálogo relativos a RelVars básicas, visões, restrições de integridade, autorização etc., mas também todas as informações de controle necessárias para permitir que o sistema forneça a desejada independência de local, fragmentação e replicação. Surge a questão: onde e como deve ser armazenado o próprio catálogo? Algumas possibilidades são: 1. centralizado o catálogo inteiro é armazenado exatamente uma vez, em um único site central; 2. totalmente replicado o catálogo inteiro é armazenado por completo em cada site; 3. particionado cada site mantém seu próprio catálogo para objetos armazenados nesse site. O catálogo total é a união de todos esses catálogos locais disjuntos; 4. combinação das abordagens 1 e 3 cada site mantém seu próprio catálogo local, como no item 3; além disso, um único site central mantém uma cópia unificada de todos esses catálogos locais, como no item 1. Cada uma dessas abordagens tem seus problemas. A abordagem 1 evidentemente viola o objetivo de não dependência de um site central. A abordagem 2 sofre de uma severa perda de autonomia, pois cada atualização de catálogo deve ser propagada para todos os sites. A abordagem 3 torna as operações não locais muito dispendiosas (a localização de um objeto remoto exigirá acesso à metade da quantidade de sites, em média). A abordagem 4 é mais eficiente que a abordagem 3 (a localização de um objeto remoto exige somente um acesso ao catálogo remoto), mas viola mais uma vez o objetivo de não dependência de um site central. Assim, na prática, os sistemas em geral não usam qualquer uma dessas quatro abordagens. A título de exemplo, descrevemos a abordagem utilizada em R*. R* (o R estrela ) O asterisco é o chamado operador de Kleene R* significa zero ou mais [System] R s. Para explicar como é estruturado o catálogo do R*, primeiro é preciso dizer algo sobre a nomeação de objetos em R*. A nomeação de objetos é questão significativa para sistemas distribuídos em geral; a possibilidade de dois sites distintos X e Y conterem ambos um objeto, digamos, uma RelVar básica chamada R, implica que algum mecanismo normalmente, a qualificação pelo nome do site será necessário para desfazer a ambiguidade, isto é, garantir a unicidade de nomes no âmbito do sistema. No entanto, se nomes qualificados como X.R e Y.R forem expostos ao usuário, o objetivo de independência do local está claramente violado. Portanto, é necessário um meio de mapear os nomes conhecidos pelos usuários para seus nomes correspondentes, conhecidos pelo sistema. Aqui está então a abordagem do R* para esse problema. Primeiro, R* faz distinção entre o nome impresso de um objeto, que é o nome pelo qual o objeto é normalmente referenciado pelos usuários, por exemplo, em uma instrução SELECT da SQL e seu nome para o sistema, que é um identificador interno globalmente exclusivo para o objeto. Os nomes para o sistema têm quatro componentes: 1. ID do criador (a ID do usuário que emitiu a operação CREATE, que criou o objeto em primeiro lugar); 2. ID do site do criador (a ID do site no qual a operação CREATE foi executada); 3. Nome local (o nome não qualificado do objeto); 4. ID do site de nascimento (a ID do site em que o objeto foi inicialmente armazenado). Pós-Graduação a Distância 41

42 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III As IDs de usuários são exclusivas dentro do site, e as IDs de sites são globalmente exclusivas. Assim, por exemplo, o nome para o sistema. BRASIL. LONDRES Identifica um objeto para definir melhor; vamos considerá-lo como uma RelVar básica com o nome local STATS, criado pelo usuário chamado Marcos no site do Brasil e inicialmente armazenado no site de Londres. Esse nome tem a garantia de nunca mudar nem mesmo se o objeto migrar para outro site. Um nome impresso consiste em um nome não qualificado simples, seja o componente nome local do nome para o sistema (STATS, no exemplo anterior), seja um sinônimo desse nome para o sistema, definido por meio da instrução especial CREATE SYNONYM do R*. Aqui está um exemplo: CREATE SYNONYM MSTATS FOR BRASIL. LONDRES ; Agora, o usuário pode especificar, por exemplo: SELECT... FROM STATS... ou SELECT... FROM MSTATS... No primeiro caso (usando o nome local), o sistema deduz o nome para o sistema assumindo todos os defaults óbvios, ou seja, que o objeto foi criado por este usuário, que ele foi criado neste site e que foi armazenado inicialmente neste site. A propósito, uma consequência dessas hipóteses default é que antigas aplicações do System R funcionarão sem alterações no R*, isto é, depois que os dados do System R forem redefinidos como dado do R*. No segundo caso (usando o sinônimo), o sistema determina o nome para o sistema interrogado a tabela de sinônimos relevantes. As tabelas de sinônimos podem ser vistas como o primeiro componente do catálogo; cada site mantém um conjunto dessas tabelas para cada usuário conhecido nesse site, mapeando os sinônimos conhecidos por esse usuário nos nomes correspondentes para o sistema. Além das tabelas de sinônimos, cada site mantém: 1. uma entrada de catálogo para cada objeto nascido nesse site; 2. uma entrada de catálogo para cada objeto armazenado atualmente nesse site. Banco de Dados Distribuídos Suponha agora que o usuário emita uma requisição referente ao sinônimo MSTATS. Primeiro, o sistema procura o nome para o sistema correspondente na tabela de sinônimos apropriada (uma pesquisa puramente local). Agora, ele sabe o site de nascimento, Londres, no exemplo interrogar o catálogo de Londres (o que vamos supor, para generalizar, ser uma pesquisa remota, de modo que esse é o primeiro acesso remoto). O catálogo de Londres conterá uma entrada para o objeto, em virtude de item 1 anterior. Se o objeto ainda estiver em Londres, ele será encontrado nesse momento. Contudo, se o objeto tiver migrado para o Japão (exemplo), então a entrada no catálogo em Londres informará esse fato, de modo que agora o sistema possa interrogar o catálogo do Japão (segundo acesso remoto). E o catálogo do Brasil conterá uma entrada para o objeto, em virtude do item 2 anterior. Assim, o objeto será encontrado com no máximo dois acessos remotos. Além disso, se o objeto migrar outra vez, digamos para a Austrália, então o sistema: 1. inserirá uma entrada de catálogo da Austrália; 2. eliminará a entrada no catálogo do Japão; 3. atualizará a entrada de catálogo de Londres para indicar Austrália em vez do Brasil. 42

43 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III O efeito final é que o objeto ainda poderá ser encontrado com no máximo dois acessos remotos. E esse é um esquema completamente distribuído, não existe um site de catálogo central e nenhum ponto único de falha dentro do sistema. Saiba que o esquema de nomeação de objetos usados no recurso de dados distribuídos do DB2 é semelhante, mas não idêntico ao descrito. Propagação de atualizações O problema básico com a replicação de dados é que uma atualização de qualquer objeto lógico dado deve ser propaganda a todas as cópias armazenadas desse objeto. Surge imediatamente uma dificuldade, se algum site que tenha uma cópia do objeto não estiver disponível (devido a uma falha em um site ou na rede), no momento da atualização. A estratégia óbvia de propagar imediatamente as atualizações para todas as cópias poderia ser então inaceitável, porque implica que a atualização e, portanto, a transação falhará se qualquer uma dessas cópias não estiver disponível no momento. De replicação, minando assim uma das vantagens proclamadas para a replicação do item anterior. Um esquema comum para tratar do problema (não o único possível) é o chamado esquema de cópia primária, que funciona assim: 1. uma cópia de cada objeto replicado é designada como cópia primáriae e as demais são todas cópias secundárias; 2. cópias primárias de diferentes objetos estão em sites diferentes (assim, mais uma vez esse é um esquema distribuído); 3. operações de atualização são consideradas logicamente completas tão logo a cópia primária seja atualizada. O site que guarda essa cópia é então responsável pela propagação da atualização para as cópias secundárias em algum momento subsequente. Esse momento subsequente deve ser anterior ao COMMIT, se as propriedades ACID da transação tiverem de ser preservadas. As exigências ACID de processamento de transações implicam que toda propagação de atualização deve ser concluída antes que a transação em questão possa se completar ( replicação síncrona ). No entanto, vários produtos comerciais admitem atualmente uma forma menos ambiciosa de replicação, na qual a propagação de atualizações é feita em algum momento posterior, talvez em algum momento especificado pelo usuário, não necessariamente dentro do escopo da transação relevante ( replicação assíncrona ). Na verdade, o termo replicação infelizmente foi mais ou menos usurpado por esses produtos, resultando que pelo menos no mercado comercial quase sempre ele é tomado com o significado de que a propagação de atualizações é postergada além do ponto de COMMIT da transação relevante. Um dos problemas com essa abordagem de propagação postergada é que o banco de dados não pode mais ter a garantia de ser consistente tempo todo; de fato, o usuário pode nem, sequer, saber se ele está consistente ou não. Pós-Graduação a Distância 43

44 Arquitetura e Projeto de Banco de Dados Distribuídos Unidade III Recuperação O controle de recuperação em sistemas distribuídos em geral se baseia no protocolo do COMMIT em duas fases, ou alguma variante dele. O COMMIT em duas fases é exigido em qualquer ambiente em que uma única transação pode interagir com vários gerenciadores de recursos autônomos; porém, é particularmente importante em um sistema distribuído, porque os gerenciadores de recursos em questão, isto é, os SGBDs locais, estão operando em sites distintos e, portanto, são muitos autônomos. Surgem pontos importantes: 1. o objetivo de não dependência de um site central determina que a função de coordenador não deve ser atribuída a um site específico na rede, mas ser realizada por sites diferentes para transações diferentes. Em geral, ela é tratada pelo site no qual a transação em questão é iniciada; assim, cada site deve ser capaz de atuar como site coordenador para algumas transações e como site participante em outras (em geral); 2. o processo de COMMIT em duas fases exige que o coordenador se comunique com todos os sites participantes o que significa mais mensagens e maior sobrecarga; 3. se o site Y atuar como participante em um processo de COMMIT em duas fases coordenado pelo site X então Y deve fazer o que for determinado pelo site X (COMMIT ou ROLLBACK, o que for aplicável): uma perda de autonomia local, embora talvez uma pequena perda. Para simplificar, vamos supor que o coordenador e o participante estão em sites diferentes; além disso, suponhamos que a transação tenha solicitado um COMMIT, e não um ROLLBACK. Ao receber essa requisição de COMMIT, o coordenador executa o seguinte processo em duas fases: 1. ele instrui cada participante a ficar pronto para seguir um dos caminhos na transação; 2. quando o coordenador recebe respostas de todos os participantes, ele toma sua decisão (que será commit se todas as respostas foram OK e rollback em caso contrário). Concorrência Na maioria dos sistemas distribuídos, o controle de concorrência se baseia no bloqueio, exatamente como na maioria dos sistemas não distribuídos. Porém, em um sistema distribuído, requisições para testar, impor e liberar bloqueios se tornam mensagens (supondo-se que o objeto em consideração esteja em um site remoto), e mensagens significam sobrecarga. Por exemplo: considere uma transação T que precise atualizar um objeto para o qual existem réplicas em n sites remotos. Se cada site é responsável por bloqueios sobre objetos armazenados nesse site (como acontecerá sob a hipótese de autonomia local), então uma implementação direta exigirá pelo menos 5n mensagens: 1. n requisições de bloqueio; 2. n concessões de bloqueio; Banco de Dados Distribuídos 3. n mensagens de atualizações; 4. n confirmações; 5. n requisições de desbloqueio. Podemos facilmente melhorar essa implementação usando mensagens de carona, por exemplo. As mensagens de requisição de bloqueio e de atualização podem ser combinadas, do mesmo modo que as mensagens de concessão de bloqueio e de confirmação, mas, mesmo assim, o tempo total para a atualização ainda poderá ser várias ordens de grandeza maior do que seria em um sistema centralizado. 44

45 Unidade III Controle, Sincronização e Atualização em Sistemas Distribuídos Capítulo 8 Processamento de Consulta, Sistemas de Diretórios e Protocolos de Acesso ao Diretório Processamento de Consulta O processamento da consulta em um banco de dados heterogêneo pode ser complicado. Algumas das questões são: Dada uma consulta em um esquema global, a consulta pode ter de ser traduzida para consultas em esquemas locais em cada um dos sites em que ela precisa ser executada. Os resultados da consulta precisam ser traduzidos de volta para o esquema global. A tarefa é simplificada pela escrita origem de dados, que oferece uma visão dos dados locais no esquema global. Os wrappers também traduzem consultas no esquema global para consultas no esquema local, e traduzem resultados de volta para o esquema global. Wrappers podem ser fornecidos por sites individuais ou podem ser escritos separadamente como parte do sistema de multibanco de dados. Os wrappers podem ainda ser usados para oferecer uma visão relacional das origens de dados não relacionais, como páginas Web (possivelmente com interfaces de formulários), arquivos puros, bancos de dados hierárquicos e de rede, além de sistemas de diretório. Algumas origens de dados podem oferecer apenas capacidades limitadas de consulta, por exemplo, elas podem admitir seleções, mas não junções. Elas podem, ainda, restringir a forma das seleções, permitindo-as apenas sobre certos campos; as origens de dados da Web com interfaces de formulário são um exemplo de tais origens de dados. As consultas, portanto, podem ser desmembradas, para serem parcialmente realizadas na origem de dados e parcialmente no site que emite a consulta. A otimização de consulta global em um banco de dados heterogêneo é difícil, pois o sistema de execução de consulta pode não saber quais custos são de planos de consulta alternativos nos diferentes sites. A solução normal é contar apenas a heurística no nível global. Sistemas mediadores são sistemas que integram várias origens de dados oferecendo uma visão global integrada dos dados e facilidades de consulta na visão global. Ao contrário dos sistemas multibanco de dados com todos os recursos, os sistemas mediadores não se importam com o processamento da transação. Os termos mediador e multibanco de dados normalmente são usados de uma maneira intercambiável, e os sistemas que são chamados mediadores podem admitir formas limitadas de transação. O termo banco de dados virtual é usado para se referir a sistemas multibanco de dados/ mediadores, pois oferecem a aparência de um único banco de dados com um esquema global, embora existam dados em vários sites nos esquemas locais. Pós-Graduação a Distância 45

46 Controle, Sincronização e Atualização em Sistemas Distribuídos Unidade IV Sistemas de Diretório Considere uma organização que queira tornar os dados sobre seus funcionários disponíveis a uma série de pessoas na organização. Alguns exemplos dos tipos de dados incluem nome, designação, id-funcionário, endereço, número de telefone, número de fax e assim por diante. Nos dias anteriores aos computadores, as organizações criariam diretórios físicos de funcionários e os distribuiriam pela organização. Ainda hoje, companhias de telefone criam diretórios físicos dos clientes. Em geral um diretório é uma listagem de informações sobre alguma classe de objetos, como pessoas. Os diretórios podem ser usados para encontrar informações sobre um objeto específico ou, na direção reversa, para encontrar objetos que atendem a um certo requisito. No mundo dos diretórios de telefone físicos (os catálogos telefônicos), aqueles que satisfazem as pesquisas na direção normal são chamados páginas brancas, enquanto os diretórios que satisfazem pesquisas na direção contrária são chamados páginas amarelas. No mundo atual interligado por redes, a necessidade de diretórios ainda está presente, e ainda é mais importante. Porém, os diretórios hoje precisam estar disponíveis por uma rede de computadores, em vez de uma forma física (papel). Protocolos de Acesso ao Diretório LDAP As informações de diretório podem se tornar disponíveis por meio de interfaces da Web, como fazem muitas organizações, principalmente companhias telefônicas. Essas interfaces são boas para os humanos. Porém, os programas também precisam acessar informações de diretório. Os diretórios podem ser usados para armazenar outros tipos de informações, muito semelhantes aos diretórios do sistema de arquivos. Por exemplo, os navegadores Web podem armazenar marcadores pessoais e outras configurações de navegador em um sistema de diretório. Um usuário pode, assim, acessar as mesmas configurações a partir de vários locais, como em casa e no trabalho, sem ter de compartilhar um sistema de arquivos. Vários protocolos de acesso a diretório foram desenvolvidos para oferecer uma forma padronizada de acessar dados em diretório. O mais utilizado, entre eles, hoje é o Lightwight Directory Access Protocol LDAP. Obviamente, todos os tipos de dados em nossos exemplos podem ser armazenados sem muito trabalho em um sistema de banco de dados e acessados por meio de protocolos como o SQL ou ODBC. Logo, a questão é: por que a necessidade de um protocolo especializado para acessar informações de diretório? Existem pelos menos duas respostas para a pergunta: Primeira, os protocolos de acesso ao diretório são protocolos simplificados, que satisfazem um tipo limitado de acesso aos dados. Eles evoluíram em paralelo com os protocolos de acesso ao banco de dados. Banco de Dados Distribuídos Segunda, e mais importante, os sistemas de diretório oferecem um mecanismo simples para nomear objetos de uma forma hierárquica, semelhante aos nomes de diretório do sistema de arquivos, que podem ser usados em um sistema de diretório distribuído para especificar que informações são armazenadas em cada um dos servidores de diretório. Por exemplo, determinado servidor de diretório pode armazenar informações para os funcionários da Bell Laboratories, em Murray Hill, enquanto outro pode armazenar informações para funcionários da Bell Laboratories, em Bangalore, dando a ambos os sites autonomia no controle de seus dados locais. O protocolo de acesso ao diretório pode ser usado para obter dados dos dois diretórios, através de uma rede. Mais importante, o sistema de diretório pode ser configurado para encaminhar automaticamente as consultas feitas em um site para outro, sem intervenção do usuário. Por esses motivos, várias organizações possuem sistemas de diretórios para tornar as informações organizacionais disponíveis on-line por meio de um protocolo de acesso ao diretório. As informações em um diretório organizacional podem ser usadas para uma série de propósitos, como descobrir endereço, telefone ou endereço de das pessoas, descobrir em quais departamentos as pessoas estão, acompanhar hierarquias de departamento. Os diretórios também são usados para autenticar usuários: aplicações podem coletar informações de autenticação, como as senhas dos usuários, e autenticá-los usando o diretório. Como poderíamos esperar, várias implementações de diretório acham benefício usar bancos de dados relacionais para armazenar dados, em vez de criar sistemas de armazenamento de uso especial. 46

47 Para (não) Finalizar Nesta disciplina, conhecemos as principais metodologias de sistemas de banco de dados distribuído, que consiste em uma coleção de sites, cada um mantendo um sistema de banco de dados local. Cada site é capaz de processar transações locais: aquelas transações que acessam dados apenas nesse site isolado. Além disso, um site pode participar na execução de transações globais: aquelas transações que acessam dados em vários sites. A execução de transações globais requer a comunicação entre os sites. O aprendizado é integrar esses conhecimentos de banco de dados distribuído com as outras disciplinas estudadas e, ainda, as que estão por vim. É um grande objetivo do profissional de banco de dados distribuídos, ou um DBA, inovar, criar, elaborar e manter projetos eficazes de banco de dados distribuído e aplicar os conhecimentos em prol da TI da sua empresa. Pós-Graduação a Distância 47

48 Referências DATE, C. J. Introdução a sistemas de banco de dados. Tradução da 8. ed. americana, Rio de Janeiro: Editora Elsevier, MEYER, L. A. V. C.; MATTOSO, M. L. Q. Sistemas de banco de dados distribuídos e paralelos: parallelism in database management systems, Tutorial nos Anais do XII Simpósio Brasileiro de Banco de Dados, Apostila publicada como separata, 38 p. NAVATHE, Elmasri. Sistema de banco de dados. 4. ed. São Paulo: Pearson, ÖZSU, M. Tamer; VALDURIEZ Patrick. Princípios de sistemas de banco de dados distribuídos. Tradução da 2. ed. americana. Rio de Janeiro: Campus, SILBERSCHATZ, Abraham; SUDARSHAN Korth S. Sistema de banco de dados. Tradução da 5. ed. americana.rio de Janeiro: Elsevier, Banco de Dados Distribuídos 48