BDD2

2.232 visualizações

Publicada em

Conceitos de Banco de Dados Distribuídos e Replicação de Dados

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.232
No SlideShare
0
A partir de incorporações
0
Número de incorporações
56
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

BDD2

  1. 1. Conceitos de Banco de Dados Distribuídos e Replicação de Dados Robson Soares Silva [email_address]
  2. 2. BD Centralizado
  3. 3. Esquema Conceitual <ul><li>A descrição a nível lógico forma o esquema conceitual do banco de dados. O esquema 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. </li></ul><ul><li>O esquema conceitual consiste de um conjunto de estruturas de dados descrevendo como os dados estão organizados do ponto de vista lógico, além de um conjunto de restrições de integridade indicando que conjuntos de dados corretamente refletem situações do mundo real. </li></ul><ul><li>A classe de estruturas de dados e restrições de integridade permitidas são determinadas pelo modelo de dados escolhido. </li></ul>
  4. 4. Esquema Interno <ul><li>Ao nível interno ou físico, 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. O resultado é chamado de esquema interno do banco. A existência de um esquema interno separado do esquema conceitual é bastante importante pois os detalhes de armazenamento do banco devem ser transparentes (ou mesmo irrelevantes) ao desenvolvimento de programas de aplicação. O esquema interno não deve ser visível aos usuários ou analistas de aplicação, sendo responsabilidade do administrador do banco definí-lo.Além disto, 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. Ou seja, o SGBD deve permitir alcançar o que chamamos de independência física de dados. </li></ul>
  5. 5. Esquema Externo <ul><li>Pode-se criar uma visão especializada do banco para cada grupo de usuários, ainda do ponto de vista lógico, através da definição de um esquema externo para cada grupo. </li></ul><ul><li>Esquemas externos facilitam o desenvolvimento de aplicações já que focalizam apenas a parte do banco que interessa à aplicação, escondendo parte da complexidade do banco. </li></ul><ul><li>Esquemas externos também são úteis como uma forma de restringir o acesso a dados classificados por parte de grupos de usuários. </li></ul>
  6. 6. BD Distribuído
  7. 7. BDD <ul><li>A descrição de um banco de dados distribuído, reflete os requisitos de que a localização e replicação dos dados deve ser transparente aos usuários do BDD e de que o sistemas locais devem manter sua autonomia. </li></ul>
  8. 8. BDD deve ser transparente ao usuário <ul><li>O requisito postulando que a distribuição do BDD deve ser transparente ao usuário pode ser entendido como indicando que, a nível lógico, um BDD deve ser visto como se fosse um banco de dados centralizado. Desta forma, deve existir: </li></ul><ul><ul><li>um esquema conceitual global descrevendo o BDD a nível lógico e ignorando o fato deste ser distribuído </li></ul></ul><ul><ul><li>vários esquemas externos globais descrevendo visões do BDD para grupos de usuários. </li></ul></ul>
  9. 9. Esquema conceitual global de um BDD <ul><li>O esquema conceitual global não é mapeado diretamente em esquemas internos nos diversos nós onde residirá o banco. Esta alternativa aglutinaria em um único passo os problemas de se definir tanto o critério de distribuição do banco como também a estratégia de armazenamento do banco em cada nó. Para evitar este inconveniente, introduz-se para cada nó onde uma parte do banco estará armazenada um 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. </li></ul><ul><li>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 . Cada nó possui, portando, uma descrição completa, a nível lógico e físico, do banco ali armazenado. </li></ul>
  10. 10. Tipos de Replicação no SQL Server <ul><li>Snapshot </li></ul><ul><li>Transaction </li></ul><ul><li>Merge </li></ul>
  11. 11. Snapshot <ul><li>Snapshot: Copia uma área de visão de dados inteira para outro computador. O banco de dados destino é escrito sobre o original com a nova versão. A replicação snapshot distribui os dados exatamente da forma como eles aparecem em um momento específico e não faz monitoramento para atualizações dos dados. O melhor uso para a replicação snapshot é como um método de reproduzir os dados que sofrem poucas mudanças ou onde os valores mais atualizados, de latência baixa, não são requisitos. Quando ocorre a sincronização, o snapshot inteiro é gerado e enviado para os Assinantes ( Subscribers ). </li></ul>
  12. 12. Transacional <ul><li>Transacional. Transações, declarações INSERT, UPDATE, ou DELETE, executados em um computador são replicados para outro computador. Com a replicação transacional, um snapshot inicial dos dados é aplicado aos assinantes, e então as transações individuais são capturadas e propagadas para os Assinantes quando são realizadas as modificações dos dados no Editor. A replicação transacional é útil quando: </li></ul><ul><ul><ul><li>Mudanças incrementais não precisam ser propagadas para assinantes assim que elas ocorrem; </li></ul></ul></ul><ul><ul><ul><li>Transações precisam estar de acordo com as propriedades Atômica, Consistência, Isolamento e Durabilidade (ACID); </li></ul></ul></ul><ul><ul><ul><li>Assinantes estão conectados com freqüência e de forma confiável ao Editor. </li></ul></ul></ul>
  13. 13. Merge <ul><li>Atualizações em qualquer computador serão replicadas para outro computador futuramente. A replicação Merge é o processo de distribuição de dados do Editor para Assinantes, permitindo tanto ao Editor quanto aos Assinantes fazer atualizações enquanto conectados ou desconectados, e então unificar ( merge ) as atualizações entre os sites quando estes forem conectados. </li></ul>
  14. 14. Replicação com uso de triggers <ul><li>Pode-se usar triggers para fazer a replicação de dados de tabelas de um banco de dados </li></ul>
  15. 15. TRIGGER DE REPLICAÇÃO DO TIPO TRANSACTION <ul><li>ALTER TRIGGER INSREPLIC_TRANSACTION ON Cliente </li></ul><ul><li>FOR insert </li></ul><ul><li>AS </li></ul><ul><li>INSERT INTO Cliente_Replica </li></ul><ul><li>SELECT * from Inserted </li></ul><ul><li>PRINT 'ATUALIZAÇÃO TRANSACTION </li></ul><ul><li>EFETUADA COM SUCESSO!' </li></ul>

×