Arquitetura Genérica do SGBDD

Transcrição

1 Bancos de Dados III Bancos de Dados Distribuídos Arquiteturas, Modelos e Requisitos Rogério Costa [email protected] 1 Arquitetura Genérica do Existem diversas propostas de arquiteturas para BDD (multi-database, federação,...) Um SGBD distribuído pode ser visto como uma federação de SGBDs centralizados, autônomos, chamados de SGBDs locais, que são interligados por uma camada de software chamada de SGBD da rede ou SGBD global 2 1

2 Arquitetura Genérica do Um SGBD local: É como um SGBD centralizado gerenciando de forma autônoma o banco de dados local, exceto que poderá receber comandos tanto de usuários locais quanto da cópia local do SGBD global. 3 Arquitetura Genérica do A coletividade dos bancos locais constitui, então, uma implementação do banco distribuído. O SGBD global roda como uma aplicação sob o sistema operacional da rede de comunicação de dados. Isto significa que todos os problemas de comunicação de dados e distribuição de recursos é transparente ao SGBD global. 4 2

3 Arquitetura Genérica do Exemplo com ambiente de Federação de Bancos de Dados 5 Tipos de s Homogêneo vs Heterogêneo Homogêneo (em "software") : se os SGBDs locais são semelhantes oferecem interfaces idênticas ou, pelo menos, da mesma família; fornecem os mesmos serviços aos usuários em diferentes nós. Heterogêneo Caso contrário ao anterior Classificação semelhante pode ser feita com base no hardware. 6 3

4 Tipos de s Homogêneo vs Heterogêneo s homogêneos aparecem com mais freqüência quando a aplicação a que se destinam não existia antes. s heterogêneos surgem usualmente quando há necessidade de integrar sistemas já existentes. 7 Classificação dos Usuários de dbas, analistas, programadores, usuários casuais, paramétricos... Usuários globais: observam o banco de dados distribuído como um todo e acessam os dados através das interfaces do SGBD global; Usuários locais: têm contato apenas com o banco de dados local ao nó onde residem e interagem apenas com o SGBD local. 8 4

5 Requisitos Funcionais de um A forma como o banco de dados está armazenado deve ser definida pelo administrador, mas não deve ser visível aos outros tipos de usuários Detalhes de armazenamento devem ser transparentes ao desenvolvimento de programas de aplicação e ao uso casual do banco, já que a este nível apenas a forma com que os dados estão logicamente estruturados importa. Espera-se que seja possível mudar a forma de armazenar o banco sem alterar os programas de aplicação Independência física de dados. 9 Requisitos Funcionais de um Independência de ização e Replicação A localização do BD não deve causar problemas de implementação (exceto, é claro, na variação do tempo de acesso). Eventuais replicações também devem ser transparentes O sistema deve ser responsável por localizar os dados e atualizar todas as cópias. Além disto, se os arquivos forem movidos de um nó para outro, ou divididos, os usuários não devem tomar conhecimento do fato. Em resumo, os usuários globais deverão ver o banco de dados distribuído como se fosse centralizado => Independência de localização e replicação. 10 5

6 Requisitos Funcionais de um Autonomia Este requisito está intrinsecamente ligado à estruturação de um SGBD distribuído em uma federação de SGBDs locais autônomos interligados pelo SGBD global. Nesta arquitetura exige-se que cada SGBD local mantenha sua autonomia: cada SGBD deve manter controle sobre seus próprios dados => distribuição da responsabilidade dos dados para os próprios usuários locais; programas que acessem dados locais devem ser executados localmente, sem que seja necessário consultar outros nós. Como conseqüência deste requisito, um usuário local deverá acessar os dados locais como se constituíssem um banco de dados centralizado independente. 11 Requisitos Funcionais de um Interfaces de Muito Alto Nível A linguagem para acesso aos dados armazenados no banco deve ser de muito alto nível, ou seja, com as seguintes características: a linguagem deve ser não-procedimental no sentido do usuário especificar que dados devem ser acessados e não como eles devem ser acessados (isto é problema do sistema); os comandos de acesso ao banco, oferecidos pela linguagem, devem manipular conjuntos de objetos e não apenas um objeto de cada vez; os comandos devem ser completamente independentes dos detalhes de armazenamento do banco e da existência de caminhos de acesso pré-definidos. 12 6

7 Requisitos Funcionais de um Otimização Automática O uso de interfaces de alto nível perderia o impacto se o processamento de comandos para acesso aos dados fosse ineficiente. O deve, portanto, conter um otimizador para selecionar os caminhos de menor custo para acessar os dados. 13 Requisitos Funcionais de um Reestruturação Lógica do Banco e Suporte a Visões Modificações nas estruturas lógicas do banco (ou seja, na forma como os usuários vêem a estruturação dos dados) são necessárias quando a aplicação muda conceitualmente. O deve, então, fornecer meios para modificar a estrutura lógica de um banco já existente e criar a nova versão dos dados a partir da antiga. Reestruturações deste tipo podem causar impacto nos programas de aplicação => utilizar visões para minorar o impacto 14 7

8 Requisitos Funcionais de um Segurança dos Dados Uma aplicação baseada em um banco de dados facilita enormemente o acesso aos dados operacionais, o que traz o efeito adverso de facilitar acessos não autorizados a dados classificados. O deverá, necessariamente, prover meios para definir critérios de autorização para acesso aos dados e meios para assegurar que as regras de acesso serão cumpridas. 15 Requisitos Funcionais de um Suporte à Administração dos Dados Um banco de dados é, em geral, uma estrutura complexa com centenas de tipos de objetos diferentes, armazenados de diversas formas. A tarefa de administrar um banco, especialmente se é distribuído, exige ferramentas especiais para ser efetivamente executada. O deve, então, fornecer um dicionário ou diretório, onde é armazenada a descrição do banco, ferramentas para acesso a este dicionário, além de utilitários para manutenção do banco. 16 8

9 Arquitetura em 3 Camadas Três níveis de esquemas: conceitual, interno e externo E squema E squema Modelo de dados proposto pelo comitê SGBD ANSI/SPARC 17 Descrição de BD Centralizados conceitual deve apresentar uma visão de alto nível do banco, independente da forma de armazenamento refletindo apenas a semântica do empreendimento que está sendo modelado. 18 9

10 Descrição de BD Centralizados interno obtém-se uma representação eficiente do esquema conceitual em termos dos métodos de acesso e estruturas de arquivos oferecidas pelo sistema de gerência de banco de dados. Independência física de dados: espera-se de um bom sistema de gerência de banco de dados que permita mudar o esquema interno do banco sem alterar os programas de aplicação. 19 Descrição de BD Centralizados externo visão especializada do banco para cada grupo de usuários, no ponto de vista lógico 20 10

11 Arquitetura em três camadas Aplicação 1 Aplicação 2 Aplicação 3 Visões para Usuários Visões para Usuários Visões para Usuários Tabelas e Relacionamentos Implementação física 21 s Exemplos: : Implementado por Views CREATE VIEW V1(CV1,CV2) AS SELECT C1, C2 FROM T1 : Implementado por Tabelas CREATE TABLE T1 (COL1 CHAR[10] NOT NULL, COL2 DECIMAL NOT NULL); : Implementado Internamente Arquivos... struct TABLE T1 { CHAR col1[10]; FLOAT col2;} 22 11

12 Descrição do BDD 23 Descrição do BDD Existe um descrevendo o BDD a nível lógico e ignorando o fato deste ser distribuído 24 12

13 Descrição do BDD Existe vários esquemas externos globais descrevendo visões do BDD para grupos de usuários. 25 Descrição do BDD Idêntico para bancos de dados centralizados e distribuídos

14 Descrição do BDD Existe esquema conceitual local descrevendo o banco de dados local. O mapeamento do esquema conceitual global para os vários esquemas conceituais locais define, então, o critério de distribuição usado. 27 Descrição do BDD A estratégia de armazenamento de cada banco de dados local é definida mapeando-se o esquema conceitual local que o define em um esquema interno local

15 global é construído num site central. Os dados permanecem fisicamente armazenados nos sites remotos, mas o usuário tem uma visão única do universo de dados através de visões construídas sobre o esquema conceitual global. site central site remoto 2 esquema global site remoto 1 esquema local esquema local 29 Descrição do BDD Como os sistemas locais devem manter sua autonomia, faz sentido ter esquemas externos locais em cada nó descrevendo visões do banco de dados local para cada grupo de usuários locais

16 s Locais e Globais Visões Visões SITE 1 SITE 2 GLOBAL SITE 3 GCS Visões Visões Visões Visões Visões Visões LCS LOCAL LCS LOCAL LCS LOCAL Dados Físicos Dados Físicos Dados Físicos 31 Catálogo O site central precisa conter, de fato, dois conjuntos de informações conhecidos como CATALOGO GLOBAL: o esquema global: visões, tabelas, colunas globais o esquema de distribuição fragmentos de tabelas: como as tabelas estão distribuídas pelos sites através de fragmentação horizontal. fragmentos de colunas (para cada site): como as tabelas estão distribuídas pelos sites através de fragmetnação vertical

17 Descrição do BDD Homogêneo e Heterogêneo BDD homogêneo todos os esquemas a nível lógico utilizarão o mesmo modelo de dados. 33 Visões e Consultas ao Catálogo Visões globais executadas através de comandos SQL distribuídos, que trazem a especificação da fragmentação. O formato geral: SITE.TABELA.COLUNA Exemplo: CREATE VIEW GV1 AS SELECT SITE1.T1.C1, SITE1.T1.C2, SITE2.T1.C4 FROM SITE1.T1, SITE2.T1 WHERE SITE1.T1.C1 = SITE2.T1.C1 AND SITE2.T1.C4 > 1000 A construção dos esquema conceitual global simplifica as consultas: TABELA GLOBAL: GT1 SITE1.T1.C1 ALIAS: GC1 SITE1.T1.C2 ALIAS: GC2 SITE1.T1.C3 ALIAS: GC3 SITE2.T1.C4 ALIAS: GC4 O novo comando: SELECT GC1, CG2, CG4 FROM GT1 WHERE GC1 = GC4 AND GC4 >

18 Descrição do BDD Homogêneo e Heterogêneo BDD heterogêneos esquema conceitual global esquemas externos globais esquemas conceituais locais esquemas externos locais no modelo de dados pivot podem ser tanto no modelo de dados pivot, para usuários globais, ou em um modelo de dados local, no caso de se desejar oferecer a um usuário local uma visão do BDD no modelo que ele está acostumado no modelo de dados local; no modelo de dados local. 35 Projeto de BDD O projeto do esquema conceitual global e o dos esquemas externos globais é inteiramente semelhante ao caso centralizado. já que o BDD deverá se comportar como centralizado perante os usuários globais

19 Projeto de BDD O projeto dos esquemas internos locais é idêntico ao de bancos centralizados exceto que a carga imposta por acessos remotos aos dados locais também deve ser levada em consideração. 37 Projeto de BDD O problema básico de projeto de BDD reside no projeto dos esquemas conceituais locais, pois estes refletem a estratégia de distribuição do banco

20 Especificação das Interfaces de um Um é constituído de uma coleção de SGBD locais interligados por um SGBD global. Em cada nó, os usuários locais e globais devem ser atendidos Há, portanto, duas classes de interfaces em um SGBD distribuído: as interfaces globais, oferecidas pelo SGBD global aos usuários globais; as interfaces locais, oferecidas pelos SGBDs locais aos usuários locais. 39 Especificação das Interfaces de um SGBD global deverá se comportar como um SGBD centralizado perante seus usuários, e o SGBD local é, para efeito dos usuários locais, um SGBD centralizado autônomo. Para especificar as características das interfaces oferecidas tanto a usuários locais quanto a usuários globais, basta estudar os tipos de interfaces comumente oferecidas por SGBDs centralizados, ou seja: uma linguagem de definição de dados (LDD) usada para definir novos bancos de dados; uma ou mais linguagens de manipulação de dados (LMDs) usadas para recuperar e modificar os dados armazenados no banco; utilitários para manutenção do banco

21 Influência do Tipo de Homogêneo sobre as Interfaces Em um homogêneo todos os SGBDs locais oferecem interfaces idênticas => o mesmo modelo de dados, a mesma LDD e as mesmas LMDs. SGBD global ofereça as mesmas interfaces. Qualquer usuário, local ou global, poderá acessar tanto dados locais quanto dados remotos através da mesma LMD. 41 Influência do Tipo de Heterogêneo sobre as Interfaces Em sistemas heterogêneos, os SGBDs locais potencialmente usam modelos de dados e LMDs diferentes. Uma opção seria o SGBD global oferecer ao usuário global, residente em um dado nó, uma visão do banco de dados distribuído no mesmo modelo de dados que o banco local, e permitir que este usuário acesse dados definidos nesta visão através da própria LMD local. Não é necessário ensinar uma nova LMD aos usuários residentes em um determinado nó para que possam acessar dados remotos. SGBD global possui, na verdade, uma interface diferente para cada nó. SGBD global pode ainda suportar uma LMD independente, chamada LMD pivot

22 Exemplo de Ciclo de Processamento em um 1. Uma transação T operando no nó i (ou usuário acessando o banco através do nó i) executa um comando para acessar o banco T G Dj Rede G Ti G D i SGBDLj DD SGBDLi BDL BDL O gerente de transações do nó i: intercepta o comando, acessa o diretório global (que pode estar em outro nó) e cria um plano de acesso ao BDD para obter os dados necessários, ou seja, cria uma seqüência de comandos a serem enviados aos outros nós e para o próprio banco local Exemplo de Ciclo de Processamento em um T GDj Rede GTi GDi SGBDLj DD SGBDLi BDL BDL 44 22

23 Exemplo de Ciclo de Processamento em um 3. O gerente de transações do nó i: envia comandos aos nós envolvidos e coordena a sua execução T GDj Rede GTi GDi SGBDLj DD SGBDLi BDL BDL 45 Exemplo de Ciclo de Processamento em um 4. O gerente de dados de um nó j envolvido no processamento recebe comandos para o banco local e se encarrega de chamar o SGBD local para executá-los. Se for necessário, o gerente de dados traduz os comandos para a linguagem de manipulação de dados local; T tradução GDj Rede GTi GDi SGBDLj DD SGBDLi BDL BDL 46 23

24 Exemplo de Ciclo de Processamento em um 4. O gerente de dados do nó j devolve os dados pedidos ao gerente de transações do nó i; 5. O gerente de transações do nó i completa o processamento do comando submetido, passando os dados para a transação (ou para o usuário). T GDj Rede GTi GDi SGBDLj DD SGBDLi BDL BDL 47 24