Sistema de banco de dados federado - Federated database system

Um sistema de banco de dados federado é um tipo de sistema de gerenciamento de meta- banco de dados (DBMS), que mapeia de forma transparente vários sistemas de banco de dados autônomos em um único banco de dados federado . Os bancos de dados constituintes são interconectados por meio de uma rede de computadores e podem ser descentralizados geograficamente. Como os sistemas de banco de dados constituintes permanecem autônomos, um sistema de banco de dados federado é uma alternativa contrastável para a tarefa (às vezes assustadora) de mesclar vários bancos de dados distintos. Um banco de dados federado, ou banco de dados virtual , é um composto de todos os bancos de dados constituintes em um sistema de banco de dados federado. Não há integração de dados real nos bancos de dados distintos constituintes como resultado da federação de dados.

Por meio da abstração de dados , os sistemas de banco de dados federados podem fornecer uma interface de usuário uniforme , permitindo que usuários e clientes armazenem e recuperem dados de vários bancos de dados não contíguos com uma única consulta - mesmo se os bancos de dados constituintes forem heterogêneos . Para esse fim, um sistema de banco de dados federado deve ser capaz de decompor a consulta em subconsultas para envio aos DBMSs constituintes relevantes , após o que o sistema deve compor os conjuntos de resultados das subconsultas. Como vários sistemas de gerenciamento de banco de dados empregam diferentes linguagens de consulta , os sistemas de banco de dados federados podem aplicar wrappers às subconsultas para traduzi-las nas linguagens de consulta apropriadas .

Definição

McLeod e Heimbigner foram os primeiros a definir um sistema de banco de dados federado em meados dos anos 1980.

Um FDBS é aquele que "define [s] a arquitetura e interconecta os bancos de dados que minimizam a autoridade central, mas suportam o compartilhamento parcial e a coordenação entre os sistemas de banco de dados". Esta descrição pode não refletir com precisão a definição de McLeod / Heimbigner de um banco de dados federado. Em vez disso, essa descrição se encaixa no que McLeod / Heimbigner chamou de banco de dados composto . O banco de dados federado de McLeod / Heimbigner é uma coleção de componentes autônomos que tornam seus dados disponíveis para outros membros da federação por meio da publicação de um esquema de exportação e operações de acesso; não existe um esquema central unificado que englobe as informações disponíveis dos membros da federação.

Entre outras pesquisas, os profissionais definem um Banco de Dados Federado como uma coleção de sistemas de componentes cooperativos que são autônomos e possivelmente heterogêneos .

Os três componentes importantes de um FDBS são autonomia, heterogeneidade e distribuição. Outra dimensão que também foi considerada é a Rede de Computadores do Ambiente de Rede , por exemplo, muitos DBSs em uma LAN ou muitos DBSs em uma WAN, atualizando funções relacionadas aos DBSs participantes (por exemplo, sem atualizações, transições não atômicas , atualizações atômicas ).

Arquitetura FDBS

Um DBMS pode ser classificado como centralizado ou distribuído. Um sistema centralizado gerencia um único banco de dados enquanto distribuído gerencia vários bancos de dados. Um DBS componente em um DBMS pode ser centralizado ou distribuído. Um DBS múltiplo (MDBS) pode ser classificado em dois tipos, dependendo da autonomia do DBS do componente como federado e não federado. Um sistema de banco de dados não federado é uma integração de DBMS componentes que não são autônomos. Um sistema de banco de dados federado consiste em DBS componentes que são autônomos, mas participam de uma federação para permitir o compartilhamento parcial e controlado de seus dados.

As arquiteturas federadas diferem com base nos níveis de integração com os sistemas de banco de dados do componente e na extensão dos serviços oferecidos pela federação. Um FDBS pode ser categorizado como sistemas fracamente ou fortemente acoplados.

  • O Loosely Coupled requer que os bancos de dados do componente construam seu próprio esquema federado . Um usuário normalmente acessa outros sistemas de banco de dados de componentes usando uma linguagem de vários bancos de dados, mas isso remove quaisquer níveis de transparência de localização, forçando o usuário a ter conhecimento direto do esquema federado. Um usuário importa os dados de que necessita de outros bancos de dados de componentes e os integra aos seus próprios para formar um esquema federado.
  • O sistema totalmente acoplado consiste em sistemas de componentes que usam processos independentes para construir e divulgar um esquema federado integrado.

Múltiplos DBS dos quais FDBS são um tipo específico podem ser caracterizados em três dimensões: Distribuição, Heterogeneidade e Autonomia. Outra caracterização pode ser baseada na dimensão da rede, por exemplo, bancos de dados únicos ou bancos de dados múltiplos em uma LAN ou WAN .

Distribuição

A distribuição de dados em um FDBS é devido à existência de vários DBS antes de um FDBS ser construído. Os dados podem ser distribuídos entre vários bancos de dados que podem ser armazenados em um único computador ou em vários computadores. Esses computadores podem estar geograficamente localizados em lugares diferentes, mas interconectados por uma rede. Os benefícios da distribuição de dados ajudam a aumentar a disponibilidade e a confiabilidade, bem como a melhorar os tempos de acesso.

Heterogeneidade

Heterogeneidades em bancos de dados surgem devido a fatores como diferenças em estruturas, semântica de dados, restrições suportadas ou linguagem de consulta . As diferenças na estrutura ocorrem quando dois modelos de dados fornecem diferentes primitivas, como modelos orientados a objetos (OO) que oferecem suporte a especialização e herança e modelos relacionais que não oferecem . As diferenças devido a restrições ocorrem quando dois modelos oferecem suporte a duas restrições diferentes. Por exemplo, o tipo de conjunto no esquema CODASYL pode ser parcialmente modelado como uma restrição de integridade referencial em um esquema de relacionamento. CODASYL oferece suporte a inserção e retenção que não são capturadas apenas pela integridade referencial. A linguagem de consulta suportada por um DBMS também pode contribuir para a heterogeneidade entre outros DBMSs componentes . Por exemplo, diferenças nas linguagens de consulta com os mesmos modelos de dados ou diferentes versões de linguagens de consulta podem contribuir para a heterogeneidade .

Heterogeneidades semânticas surgem quando há uma discordância sobre o significado, interpretação ou uso pretendido dos dados . No esquema e no nível de dados, a classificação de possíveis heterogeneidades incluem:

  • Conflitos de nomenclatura, por exemplo, bancos de dados usando nomes diferentes para representar o mesmo conceito.
  • Conflitos de domínio ou conflitos de representação de dados, por exemplo, bancos de dados usando valores diferentes para representar o mesmo conceito.
  • Conflitos de precisão, por exemplo, bancos de dados usando os mesmos valores de dados de domínios de cardinalidades diferentes para os mesmos dados .
  • Conflitos de metadados, por exemplo, os mesmos conceitos são representados no nível do esquema e no nível da instância.
  • Conflitos de dados, por exemplo, atributos ausentes
  • Conflitos de esquema, por exemplo, conflito de tabela versus tabela que inclui conflitos de nomenclatura, conflitos de dados etc.

Ao criar um esquema federado, é necessário resolver essas heterogeneidades antes de integrar os esquemas de banco de dados do componente.

Correspondência de esquema, mapeamento de esquema

Lidar com tipos de dados incompatíveis ou sintaxe de consulta não é o único obstáculo para uma implementação concreta de um FDBS. Em sistemas que não são planejados de cima para baixo, um problema genérico consiste em combinar semanticamente equivalentes , mas com nomes diferentes de partes de esquemas diferentes (= modelos de dados) (tabelas, atributos). Um mapeamento pareado entre n atributos resultaria em regras de mapeamento (dados mapeamentos de equivalência) - um número que rapidamente fica grande demais para fins práticos. Uma saída comum é fornecer um esquema global que compreende as partes relevantes de todos os esquemas de membros e fornecer mapeamentos na forma de visualizações de banco de dados . Duas abordagens principais dependem da direção do mapeamento:

  1. Global as View (GaV): o esquema global é definido em termos dos esquemas subjacentes
  2. Local as View (LaV): os esquemas locais são definidos em termos do esquema global

Ambos são exemplos de integração de dados , chamado de problema de correspondência de esquema .

Autonomia

Fundamental para a diferença entre um MDBS e um FDBS é o conceito de autonomia. É importante entender os aspectos de autonomia para bancos de dados de componentes e como eles podem ser tratados quando um DBS de componente participa de um FDBS. Existem quatro tipos de autonomias abordadas:

  • Autonomia de design que se refere à capacidade de escolher seu design independentemente dos dados, linguagem de consulta ou conceituação, funcionalidade de implementação do sistema.

Heterogeneidades em um FDBS são principalmente devido à autonomia do projeto.

  • A autonomia de comunicação refere-se à operação geral do DBMS para se comunicar com outro DBMS ou não.
  • A autonomia de execução permite que um SGBD de componente controle as operações solicitadas por operações locais e externas.
  • A autonomia de associação dá ao DBS componente o poder de se desassociar de uma federação, o que significa que o FDBS pode operar independentemente de qualquer DBS único .

O ANSI / X3 / SPARC Study Group delineou uma arquitetura de descrição de dados de três níveis, cujos componentes são o esquema conceitual, o esquema interno e o esquema externo dos bancos de dados. A arquitetura de três níveis é, entretanto, inadequada para descrever as arquiteturas de um FDBS. Foi, portanto, alargado para suportar as três dimensões do FDBS, nomeadamente Distribuição, Autonomia e Heterogeneidade. A arquitetura do esquema de cinco níveis é explicada abaixo.

Controle de simultaneidade

Os requisitos de Heterogeneidade e Autonomia apresentam desafios especiais em relação ao controle de simultaneidade em um FDBS, que é crucial para a execução correta de suas transações simultâneas (ver também Controle de simultaneidade global ). Alcançar a serializabilidade global , o principal critério de correção, de acordo com esses requisitos, foi caracterizado como muito difícil e não resolvido. A ordem de compromisso , introduzida em 1991, forneceu uma solução geral para esse problema (consulte Serializabilidade global ; Consulte Ordem de compromisso também para os aspectos arquitetônicos da solução).

Arquitetura de esquema de cinco níveis para FDBSs

A arquitetura do esquema de cinco níveis inclui o seguinte:

  • Esquema local é basicamente o modelo conceitual de um banco de dados de componentes expresso em um modelo de dados nativo.
  • O esquema de componentes é o subconjunto do esquema local que a organização proprietária deseja compartilhar com outros usuários do FDBS e é traduzido em um modelo de dados comum.
  • Esquema de exportação representa um subconjunto de um esquema de componente que está disponível para uma federação específica. Pode incluir informações de controle de acesso relacionadas ao seu uso por um usuário de federação específico. O esquema de exportação auxilia no gerenciamento do fluxo de controle de dados.
  • Esquema federado é uma integração de vários esquemas de exportação. Inclui informações sobre a distribuição de dados que são gerados durante a integração de esquemas de exportação.
  • O esquema externo é extraído de um esquema federado e é definido para os usuários / aplicativos de uma federação específica.

Embora represente com precisão o que há de mais moderno em integração de dados, a Arquitetura de Esquema de Cinco Níveis acima apresenta uma grande desvantagem, a saber, aparência e comportamento impostos pela TI. Os usuários de dados modernos exigem controle sobre como os dados são apresentados; suas necessidades estão um tanto em conflito com essas abordagens ascendentes de integração de dados.

Veja também

Referências

  1. ^ a b c " McLeod and Heimbigner (1985). " A Federated Architecture for information management " . ACM Transactions on Information Systems, Volume 3, Issue 3. pp. 253–278.
  2. ^ a b c " Sheth e Larson (1990). " Federated Database Systems for Distributed, Heterogeneous, and Autonomous Databases " . ACM Computing Surveys, Vol. 22, No.3 . pp. 183-236.
  3. ^ a b c d e Masood, Nayyer; Eaglestone, Barry (dezembro de 2003). "Modelos de conceito de componente e federação em um sistema de banco de dados federado" (PDF) . Malaysian Journal of Computer Science . 16 (2): 47–57. Arquivado do original (PDF) em 07/03/2016 . Recuperado 2016-03-03 .

links externos