Gerência de Transações em Sistema de Banco de Dados Móvel Prof: Marcus Sampaio Aluna: Rute Cardoso Drebes Sumário Sistema de Banco de Dados Móvel Processamento de Dados em Sistema de Banco de Dados Móvel Modelos de Execução Modelos de Transação Considerações Finais Sistema de Banco de Dados Móvel Um Sistema de Banco de Dados Móvel (do inglês, Mobile Database System - MDS) oferece completa funcionalidade de banco de dados e comunicação móvel; Permite a um usuário móvel iniciar uma transação em qualquer lugar e a qualquer momento e garante a consistência preservada durante a execução; Em caso de qualquer tipo de falha (transacional, do sistema, ou da mídia utilizada), MDS garante a recuperação do banco de dados; Arquitetura de um MDS A arquitetura de um MDS oferece as seguintes propriedades essenciais, que são: Mobilidade geográfica; Conexão e desconexão; Capacidade de processamento de dados; Comunicação sem fio; Transparência; Arquitetura de um MDS Onde: PSTN: Public Switched Network; MSC : Mobile Switching Center; HLR: Home Location Register; VLR: Visitor Location Register; Amazenam o perfil do usuário e sua localização geográfica; BSC: Base Station Controller; O conjunto de PSTN e MSC’s conectam o MDS ao mundo externo; Coordenam as operações das BS’s; DBS: Database Server; BS: Base Station; MU: Mobile Unit; Tipos de Replicação de Dados Três tipos básicos de replicação de bancos de dados são mostrados: Sem replicação; Replicação tradicional distribuída (réplica temporal); Replicação dependente de localização (réplica espacial); Execução de Transações em MDS Fragmentação de uma transação em várias subtransações; É necessário um módulo coordenador, para gerenciar a transação; O que é necessário a um coordenador: Comunicação direta e contínua com outros nós; Energia contínua e ilimitada, e grande capacidade de armazenamento; Alta confiabilidade e disponibilidade; Processando uma Transação em MDS Uma transação pode ser iniciada tanto no DBS (DataBase Server) ou no MU, ou pode ser iniciada por ambos. Pode ser processada inteiramente em um nó (que pode ser tanto o de origem ou qualquer outro), ou pode haver mais de um nó envolvido na execução. Processando uma Transação em MDS Quando há mais de um nó envolvido na execução, algumas situações podem surgir: Originada DBS; Originada na MU; Executada na MU e em um conjunto do DBS; Processada somente em DBS; Processada totalmente na MU; Quando não é possível executar totalmente na MU, existem duas opções: Transferir os dados necessários do DBS para o MU; Distribuir a transação para um conjunto de nós; Processando uma Transação em MDS O movimento da MU torna a função do coordenador difícil; Devido à mobilidade, são possíveis as seguintes situações: Uma MU que não se movimenta; Uma MU em movimento; Processamento distribuído e MU em movimento; Processando uma Transação em MDS O serviço de um coordenador deve estar disponível continuamente para a MU durante a execução de uma transação. Caso haja quebra de link, devido a mobilidade, existem duas maneiras manter o link: Método estático; Método dinâmico; Processando uma Transação em MDS Quando uma unidade é altamente móvel, torna-se difícil mantê-la conectada ao seu coordenador; Soluções: 1. Definir um limite de permanência; Migração não-adjacente; 2. Um Modelo de Transação para MDS Como o modelo convencional de transação baseado nas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) não é capaz de gerenciar satisfatoriamente as tarefas de processamento móvel de dados, surge a necessidade de um novo modelo de transação para MDS. Duas abordagens propostas: Modelo de execução baseado em propriedades ACID; Modelo de transação móvel e sua execução; Modelo de Execução Baseado em Propriedades ACID A introdução de mobilidade alterou significativamente a arquitetura de banco de dados; É necessário compreender o relacionamento entre os dados, as operações que serão feitas nos dados, e a finalização da sua execução, para então poder desenvolver um modelo de execução; Com a introdução de mobilidade, surgem as questões abrangendo consultas dependentes de localização, e de dados dependentes de localização; Consulta Dependente de Localização Consulta Dependente de Localização: Um exemplo de consulta dependente de localização: Depende da origem da consulta, ou o processamento da consulta depende da mobilidade; “Qual a distância até o Aeroporto?” A resposta correta para uma consulta depende da localização geográfica da consulta e da localização geográfica dos dados necessários para respondêla; Efeitos da Mobilidade na Consistência No ambiente MDS, o conceito de consistência é mais complexo porque envolve a localização geográfica dos dados; Uma transação pode modificar valor de dados que só serão válidos para uma específica região; Uma operação idêntica de update (em localizações diferentes) pode ser submetida a diferentes parâmetros de restrição de consistência, que dependerão do local da manipulação dos dados; Modelos de Execução Desenvolvidos Existem vários modelos desenvolvidos, que diferem na maneira como esses fragmentos são executados e validados; Alguns modelos desenvolvidos são : Modelo de Consistência de Dois Níveis; Pro-Motion: Gerenciamento Pró-Ativo de Transações Móveis; Modelo de Consistência de Dois Níveis Cria clusters de dados que sejam relacionados semanticamente ou por localização; O modelo também permite que os usuários especifiquem condições para a criação dos clusters; Mantém a consistência dos dados em nível de clusters (local) e em nível de banco de dados (global); Pro-Motion: Gerenciamento Pró-Ativo de Transações Móveis Modelo focado nas questões de recursos limitados; Gerencia a execução com auxílio de Compactos; Compacto é um objeto composto de: Dados em cache; Métodos de aceso; Informação sobre o seu estado atual; Prazos e obrigações; Interface para que a MU possa gerenciá-lo; Modelos de Transação Móvel Como os Modelos de Execução possuem algumas limitações, posteriormente, Modelos de Transação Móvel foram desenvolvidos para abordar essas limitações. Alguns desses modelos são: Kangaroo; MDSTPM – Multidatabase Transaction Processing Manager; Kangaroo O modelo capta tanto os dados quanto o movimento das MU’s; Uma transação Kangaroo global (KT) é composta de várias subtransações, chamadas de Joey Transaction (JT); Quando uma transação KT é iniciada por uma MU, ela recebe uma identificação única; A BS onde a transação KT foi iniciada cria imediatamente uma subtransação JT que se torna responsável por sua execução; MDSTPM O modelo dá apoio a transações iniciadas na MU; Utiliza mensagens para estabelecer a comunicação entre a MU e BS; Possui os seguintes componentes: Gerenciador Global de Comunicação; Gerenciador Global de Transação; Gerenciador Local de Transação; Gerenciador Global de Recuperação; Considerações Finais Como o modelo de transações baseadas em propriedades ACID não consegue gerenciar satisfatoriamente as tarefas de processamento móvel de dados, surgiu a necessidade de desenvolver um modelo que pudesse lidar com a mobilidade durante o processamento dos dados; Os Modelos de Transação abordam a maioria das questões referentes a mobilidade; Apesar de haver várias propostas de métodos, nenhum se tornou um método comumente aceito; Referências KUMAR, Vijay. Mobile Database Systems. John Wiley & Sons, Inc., Hoboken, New Jersey.