Universidade Federal do Maranhão Departamento de Engenharia Elétrica Coordenação de Pós-Graduação em Engenharia Elétrica Mestrado em Ciência da Computação Banco de Dados Móveis Jackson de Oliveira Vieira São Luís -2003-
INDICE Índice 2 Índice de tabelas 4 Índice de figuras 1 Introdução 6 2 Banco de dados móveis x distribuídos 7 3 Os SGBDs e o ambiente de Computação Móvel 9 3.1 Processo de transações no ambiente de computação móvel 9 3.2 Estados de operação de um host móvel 11 3.3 Estados de operações desconectadas de um host móvel 13 3.3.1 Hoarding 13 3.3.2 Operações desconectadas 14 3.3.2 Reintegração 15 4 Checkpoints no ambiente móvel 16 5 Gerência de Dados Móveis 18 5.1 Disseminação ou difusão de dados (Broadcast) 19 6 Arquiteturas de banco de dados de localização 21 6.1 Esquemas em duas camadas 21 6.2 Esquemas hierárquicos 22 2
7 O mercado de SGBD móveis 23 7.1 Sybase Anywhere Studio 24 7.2 Oracle Lite Mobile Server 26 7.3 DB2 Everyplace 28 7.4 Microsoft SQL Server CE 30 8 Conclusão 33 9 Bibliografia 35 3
Índice de tabelas Tabela 3.1 16 Tabela 7.1 33 4
Índice de figuras Fig 2.1 7 Fig 3.1 13 Fig 5.1 19 Fig 5.2 20 Fig 6.1 23 5
1 INTRODUÇÃO Diversas atividades que envolvem alguma interação com um Sistema de Banco de Dados (SBD) estão presentes no nosso dia-a-dia. O depósitos ou a retirada de dinheiro em um banco, reservas em hotéis ou assentos de aviões, a compra de produtos em supermercado ou consultas a catálogos informatizados de uma biblioteca, são bons exemplos da utilização dos SBD na vida das pessoas. Todas essas atividades, para serem eficientes, envolvem o acesso a um banco de dados. Computadores portáteis são cada vez mais utilizados em diversos domínios de aplicações. Juntamente com as tecnologias das redes de comunicações provêem a base do hardware para a computação móvel. Os Sistemas de Banco de Dados e seus componentes básico fornecem todos os mecanismos para confiança, segurança, disponibilidade, integridade e acesso eficiente a suas bases de dados. Assim, os SBD podem estar localizados tanto nas redes fixas, desempenhando um papel relacional de servidores de dados para todas as aplicações, como podem, também, desempenhar um novo papel de servidores de dados globais e locais, agora residindo em um equipamento móvel. Este novo papel dos SBD, exigirá um novo comportamento e adaptação nos Sistemas de Gerência de Banco de Dados (SGDs), para que os mesmos possam desempenhar seus papéis na administração dos dados, em face às características do ambiente móvel. Entre estas características se destacam as constantes desconexões voluntárias ou involuntárias dos equipamentos móveis de suas redes, a fraca conectividade das redes sem fio nas quais os equipamentos móveis estão conectados e os poucos recurso dos equipamentos que hospedarão os SGBD Móveis. 6
Entre os principais objetivos deste trabalho destacam-se a utilização de banco de dados no ambiente de computação móvel, ressaltando seus novos requisitos e funcionalidades, a apresentação de diversos modelos e arquiteturas que podem ser utilizados com os banco de dados no ambiente de computação móvel, os principais problemas encontrados e como os banco de dados podem ajudar a resolver esses problemas. 2 Banco de dados móveis X Distribuídos Um sistemas de Computação Distribuídos consiste em uma série de elementos computacionais, não necessariamente homogêneos, conectados em uma rede e colaboram entre si na execução de tarefas que lhes são atribuídas. Um banco de dados distribuídos é uma coleção de bases de dados espalhadas conforme a figura a seguir. BD Local 1 Local 2 BD Local 3 Rede de comunicações BD Fig 2.1.Arquitetura de banco de dados distribuído Do ponto de vista de gerenciamento dos dados, a computação móvel pode ser considerada uma variação da computação distribuída. Banco de dados móveis podem ser distribuídos em dois possíveis cenários: 7
Toda base de dados está distribuída principalmente entre os componentes ligados por fiação, possivelmente com replicação total ou parcial dos dados. Uma base gerencia sua própria base de dados com um SGBD com funcionalidades adicionais para localizar unidades móveis e para gerenciar consultas e transações do ambiente móvel; A base de dados é distribuída pelos componentes com e sem fio. A responsabilidades do gerenciamento dos dados é compartilhada entre as unidades móveis e as estação base. Considerando os sistemas móveis como um caso especial dos sistemas distribuídos, percebe-se que enquanto muitos problemas são iguais, existem outros diferentes. Os sistemas distribuídos têm como principal objetivo a transparência de distribuição, já os sistemas móveis buscam o conhecimento da localização, ou seja, saber onde um cliente móvel está localizado geograficamente para poder manter uma comunicação constante, sem interrupções. Entre as principais características dos SGBDs móveis podemos destacar : Vários bancos de dados interligados por uma rede de comunicação sem fio; Acesso de um computador móvel (host móvel) a um banco de dado residindo em um em um computador fixo (host fixo) ou em um computador móvel O computador móvel pode desempenhar o papel de cliente ou servidor de banco de dados; Os bancos de dados são autônomos, distribuídos e provavelmente heterogêneos. Quanto à gerência e administração dos dados, diversos fatores podem influenciar o funcionamento e o desempenho de banco de dados no ambiente de computação móvel. São eles: 8
Velocidade dos links sem fio : pode demorar nas consultas; Escalabilidade : crescimento dos bancos de dados tem impacto nas consultas e limita a quantidade de dados nos banco de dados residentes em clientes móveis; Mobilidade : pode causar desconectividade e cancelamento de transações; Localização dos hosts móveis: implica na necessidade de administrar a localização dos hosts móveis para interação durante as consultas; Limite de poder das baterias: existem trabalho em modo desconectado da rede e podem causar desconexões e cancelamento de transações; Desconectividade: causam o cancelamento de transações, aumentando a necessidade de novos modelo de recuperação do banco de dados; Replicação/Caching : limitadas pelo pouco poder de memória dos hosts móveis; Handoff : aumenta a necessidade de controle e administração da localização dos host móveis. 3 Os SGBDs e o ambiente de Computação Móvel Entre os principais problemas do ambiente de computação móvel diretamente as transações dos banco de dados estão as constantes desconexões dos clientes móveis de suas redes fixas, a fraca conectividade das redes sem fio, a mobilidade dos clientes móveis por um amplo espaço geográfico e as constantes falhas da recuperação das transações. Alguns desses aspectos serão discutidos nesta secção, com o objetivo de enfatizar a importância para a gerência de dados dos SGBDs. 3.1 Processo de transações no ambiente de computação móvel O conceito de transação fornece um mecanismo para descrever unidades lógicas de processamentos do banco de dados. Uma transação é uma unidade lógica de processamento 9
do banco de dados que inclui uma ou mais operações de acesso ao banco de dados. Essas transações podem incluir operações de inclusão, exclusão, modificação ou recuperação de dados. As operações do banco de dados que formam uma transação podem ser embutidas dentro de um programa da aplicação ou podem ser especificadas de maneiras interativa através de uma linguagem de consulta de alto nível como a SQL. Se as operações do banco de dados em uma transação não atualizarem o banco de dados, mas somente recuperarem os dados, a transação é denominada como transação somente de leitura. Para assegurar a integridade dos dados, o SGBD deve garantir as seguintes propriedades das transações: Atomicidade : ou todas as operações das transações são refletidas corretamente no banco de dados ou nenhuma será; Consistência : a execução de uma transação isolada, ou seja, sem a execução concorrente de outra transação, preserva a consistência do banco de dados; Isolamento : embora diversas transações possam ser executadas de forma concorrente, o sistema garante que, para todo par de transação T i e T j, T i tem a sensação de que T j já terminou sua execução antes de T i começar, ou que T j começou a sua execução após T i terminar. Assim, cada transação não toma conhecimento de outra transações concorrentes no sistema; Durabilidade : depois da transação completar-se com sucesso, fazer seu commit, as mudanças que ela fez no banco de dados persistem, até mesmo se houver falhas no sistema. Uma computação que acessa dados em um banco de dados é comumente estruturada como uma transação atômica, com o objetivo de preservar a consistência dos dados na presença de concorrência e falhas no sistema. Entretanto, uma computação móvel que 10
acessa dados compartilhados não pode ser estruturado usando uma transação atômica. Isto se dá por que transações atômicas assumem o pressusposto de executarem isoladas, o que impede as mesmas de dividirem a sua computação é de compartilhar seus estados e resultados parciais. Já na computação móvel, considerações práticas únicas deste ambiente, exigem que as computações nos hosts móveis sejam sustentadas e apoiadas por um host de suporte a mobilidade (estação de base), tanto para computação como para comunicação de dados. Isto significa que a computação móvel precisa ser estruturada como um conjunto de transações, algumas que executem no host móvel, enquanto outras executem no host de suporte a mobilidade. Uma transação móvel, é uma transação distribuída onde alguma parte da computação é executada no host móvel e outra parte em um host fixo, não móvel. O uso de meio sem fio e a mobilidade resultante dos consumidores e produtores de dados afetam o processamento das transações de várias formas. O emprego de conexões sem fio resulta em transações longas, em função dos longos atrasos da rede. Por esta razão é que os usuários de hosts móveis evitam freqüentemente o uso dos meios sem fio, uma vez que estas conexões são caras, tanto monetariamente quanto em termos de poder de consumo dos hosts móveis, ou porque os recursos da rede não estão disponíveis na sua localização geográfica. 3.2 Estados de operação de um host móvel Em um sistema distribuído não móvel as operações em seus hosts ou são totalmente conectadas ou totalmente desconectadas. Já no ambiente móvel, existem vários graus de desconexão que vão desde a desconexão total até a fraca conexão. Como resultado, um host 11
móvel pode operar em vários estados. Adicionalmente, para conservar bateria um host móvel pode operar no estado de cochilo (doze mode). Um host móvel pode executar um protocolo de desconexão antes de desligar fisicamente da rede. Este protocolo visa garantir a transferência suficiente de dados para que o mesmo continue a operar durante o estado de desconexão. Um host móvel pode trocar seu estado de parcialmente desconcectado par executar no estado parcialmente desconectado. Enquanto permanecer nesse estado, toda a comunicação com a rede deve ser limitada em uma nova célula. Neste caso, toda a informação pertinente ao estado do host móvel deve ser transferida à estação de base da nova célula, através da execução de um protocolo handoff. A figura a seguir ilustra isso. Handoff Considerações de energia Cochilo Recebimento de mensagem Totalmente conectado Protocolo de recuperação Largura de banda pequena Parcialmente conectado Protocolo parcialmente desconectado Bateria ou falha Desconectado Protocolo de desconexão Fig 3.1 Estados de operação de um host móvel 12
3.3 Estados de operações desconectadas de um host móvel Uma nova operação nos hosts móveis com o objetivo de reduzir o consumo das baterias, principalmente em palmtops é o modo cochilo (doze mode). Nesse modo a velocidade do clock do processador é reduzida e nenhuma operação do usuário é executada. O host móvel simplesmente aguarda passivamente o rececbimento de mensagens enviadas dos demais componentes da rede, retornando ao modo normal (de execução) quando uma mensagem é recebida. Como na desconexão, esta é uma operação voluntária. Entretanto, as implicações são diferentes. No modo cochilo o host móvel é alcançável pelo resto dos sistema, e assim, pode ser induzido pelo sistema a retornar o seu modo de operação normal. Quando uma desconexão é percebida, os itens de dados são transferidos para o cliente móvel (host móvel), para bossibilitar a sua operação durante o período de desconexão. Essa carga antecipada é chamada de hoarding. E podem ter três estados: 1. Hoarding; 2. Operações desconectadas; 3. Reintegração 3.3.1 Hoarding Antes da desconexão o host móvel está no estado de carga antecipada de dados (hoarding). Neste estado os itens de dados necessários para operação são carregados na unidade móvel. Os itens podem ser simplesmente realocados ou movimentados do host fixo para a unidade móvel. Entretanto, fazendo assim, esses itens de dados se tornarão inacessíveis para outros sites. Como alternativa, os itens de dados transferidos para o host móvel depende da aplicação e do modelo de dados que o sustenta. No caso de SGBD, os 13
dados podem ser relações ou visões. No caso de modelo baseados em agentes móveis, os agentes podem ser transmitidos ao longo da rede para serem executados no cliente móvel. 3.3.2 Operações desconectadas Quando acontece uma ruptura de conexão com rede a rede fixa a unidade móvel entra no estado de desconexão. Enquanto estiver neste estado, somente pode usar dados locais. Solicitações de dados que não estão localmente disponíveis não podem ser atendidas e retornam com indicação de erro. Estas pendência podem ser organizadas em uma fila para serem atendidas quando ocorrer à próxima conexão. Aplicação com solicitações de dados não atendidas também podem suspender sua execução ou continuar trabalhando em outro processamento que não dependa dos dados solicitados. Há duas abordagens: a pessimista e a abordagem otimista. Na abordagem pessimista as atualizações são executadas somente em um site utilizando bloqueio (lock) ou alguma forma de verificação dos dados de entrada e saída (chek-in/check-out). Na abordagem de conflito nas operações. As atualizações nas unidades móveis são registradas (logged) na memória estável do cliente. As informações são armazenadas no log (diário) do sistema. O tipo de informação afeta a eficácia da reintegração das atualizações quando da reconexão, assim como a eficácia da otimização do log. A otimização do log, mantedo-o em um pequeno tamanho, é muito importante pois este logo é armazenado na memória do cliente móvel e reduz o seu tempo para propagação das atualizações e reintegração durante a reconexão. Operações de otimização no log podem ser realizadas durante as operações quando a unidade móvel está desconectada, incrementalmente cada vez que uma nova operação é inserida no log ou como um passo de pré-processamento antes da propagação ou aplicando o log na próxima reconexão. 14
3.3.3 Reintegração Quando acontece uma nova conexão com a rede fixa a unidade móvel entra no estado de reintegração. Neste estado, as atualizações do host móvel são reintegradas com as atualizações de outro sites, re-executando o seu log no host fixo. Questões referente a concorrência e seriação das transações são efetivadas em função de cada sistema em particular, visando resolver o problema da atualização sobre o mesmo objeto. A tabela a seguir apresenta os principais problemas e questões relacionadas ao estado de desconexão de uma unidade móvel. Estado Problemas e questões Abordagens Hoarding Unidade de carga Que itens carregar? Quando executar a carga dos dados? Solicitação para todos não disponíveis localmente Depende do sitema - Especificado pelo usuário - Usar as informações sobre o histórico dos acesso aos dados - Depende na aplicação para que o sistema é usado - Antes da desconexão - Em uma base regular - Retorna uma exceção/erro - Solicita uma fila para futuros serviços 15
Desconexão Reintegração O que por no LOG? Quando otimizar o LOG? Como otimizar o LOG Como integrar? Como resolver os conflitos? - Valores dos dados - Timestamps - Operações - Nas operações locais - Antes de integração Depende do sistema Reexecutando as operações do LOG - Usar semântica das aplicações - Soluções automáticas - Ferramentas para ajudar ao usuários Tabela 3.1 Principais problemas e questões relacionadas ao estado de desconexão de uma unidade móvel 4 Checkpoints no ambiente móvel Em sistemas distribuídos, a recuperação de falhas é baseada nos protocolos de checkpoints. Esses protocolos periodicamente armazenam o estado da aplicação em armazenamento estável. Após uma falha, a aplicação usa esses checkpoints para desfazer (roll back) até o último ponto salvo e reiniciar a execução. Um estado global é armazenado e usado pelo protocolo para recuperar a aplicação. O estado global inclui o estado de cada processo participante na aplicação distribuída e 16
possivelmente muitas mensagens. Para uma correta recuperação, o protocolo deve conservar recuperável o estado global da aplicação. Os algoritmo de checkpoints são classificados em duas categorias : coordenados e não-coordenados. Os protocolos coordenados necessitam que cada participante coordene seus checkpoints locais para garantir a recuperação e consistência do checkpoint global. Os protocolos não-coordenados, permitem aos participantes checkpoints independentes em seu estado local. Durante a recuperação, um esforço de coordenação é necessário para selecionar um checkpoint para cada participante criar o checkpoint global consistente. Devido à mobilidade, pequena largura de bando e desconexões, ambos os tipois de protocolos, em sua forma original, são inadequados para a computação móvel. Protocolos coordenados requerem controle de mensagens enviadas a diferentes hosts móveis para sincronizar o processo de checkpoint.. Protocolos não-coordenados permite aos participantes móveis o estado de checkpoint sem troca de mensagens. Isto é adequado para o ambiente móvel porque permite que o processo de checkpoint continue durante a desconexão. Um pequeno número de adaptações para os protocolos de checkpoint coordenados e não-coordenados tem sido desenvolvido para manusear as limitações do ambiente móvel. Estes protocolos podem ser classificados baseados nos seu grau de adaptabilidade e se os armazenamentos estáveis são considerandos um lugar relativamente seguro para armazenar o estado local da aplicação. Assim sendo, os checkpointing são classificados como soft o hard baseado nos tipos de falhas que podem ocorrer. Por exemplo descargas de bateria ou problemas no sistema operacional. Já as falhas hard são aquelas que causam problemas permanentes aos hosts móveis. Falhas hard são manuseadas pelo chamado checkpoint hard 17
que são armazenados na rede fixa, enquanto as falhas soft são ditribuídas, chckpoint soft, são armazenado no host móvel. 5 Gerência de Dados Móveis Esta seção está focada nas técnicas de gerência de informação e recuperação em sistemas móveis. Destaca-se a importância das técnicas de Disseminação ou Difusão de Dados (Broadcast) como meio de entregar a informação aos hosts móveis e o impacto da computação móvel na gerência de consultas. A maioria das tecnologias sem fio suportam a disseminação de dados broadcast para todos os elemento móveis que estão em uma célula. No modelo cliente/servidor, o servidor ou o agente localizado na estação de base pode tirar vantagem desta característica para disseminar informação para todos os cliente de sua célula. Assim, é estabelecida uma nova forma de enviar dado aos clientes, diferente da forma tradicional de envio de dados somente por solicitação (sob demanda) dos clientes. A gerência de consultas para a computação móvel deve tratar de forma eficientes consultas que envolvem a localização do usuário móvel. A localização do usuário móvel introduz vários novos problemas referentes ao armazenamento e atualização desta informação. A gerência de consulta também deve trabalhar com os recursos limitados dos hosts móveis, nos quais destacam-se o pequeno tamanho de sua tela, o escasso poder de suas baterias, o longo período de desconexão dos clientes, as transações longas de banco de dados, o pouco recurso de memória, entre outros. 18
5.1 Disseminação ou difusão de dados (Broadcast) No modelo cliente/servidor tradicional, os dados são enviados para o cliente somente sob demanda, ou seja, atendendo a uma solicitação do cliente. O servidor recebe a solicitação, process-a e retorna ao cliente a informação solicitada. Esta forma de entrega dos dados é chamada de pull-based (puxar/buscar na base). Na computação sem fio, os servidores fixos são providos de canais com relativa largura de banda que suportam a entrega dos dados por broadecast ao clientes móveis em suas célulasr. Esta facilidade de infra-estrutura propiciou a uma nova forma de entrega de dados chamada push-basde, que consiste do servidor, repetidamente, disseminar dados ao universo de clientes sem uma solicitação específica por parte dos clientes. Os próprios clientes monitoram a difusão dos dados (broadcast) e recuperam os itens de dados que eles precisam, da forma como eles chegam na transmissão. A figura a seguir apresenta um broad cast push-base. G F E D Servidor A B C AB BC EG Clientes... Fig 5.1 Forma de broadcast push-based A entrega de dados na forma broadcast push-base (impulsionada pela base) é extremamente importante para um grande conjunto de aplicações que necessitam disseminar informações para um grande número de clientes. Entre suas aplicações podem 19
citar as aplicações comunicados de emergência a policiais de uma determinada área, controle de tráfego de automóveis, informações sobre condições de tempo, renovação e novas cotas de estoques de vendedores etc. A entrega de dados na forma pull-based não pode ser escalável além da capacidade do servidor da rede. Uma limitação na entrega de dados em broadcast é que o acesso é somente seqüencial. Os clientes precisam esperar até que a solicitação de dados esteja no canal de comunicação para então pega-la. Na forma de entrega pull-base, os clientes podem ter um papel mais ativo e explicitamente solicitarem seus dados ao servidor. As formas de entrega pull-based e push podem ser combinadas, considerando os sistemas em que além do canal de broadcast, os clientes possuem um canal de broadcast, os clientes possuem um canal de alta velocidade para comunicação com o servidor, também chamado de backchanel, no qual os usuários enviam suas mensagens. Esta abordagem é também como entrega de dados híbrida. Uma característica importante desta abordagem, está no fato de que se o mesmo canal do servidor até os clientes é usado sob demanda dos clientes, então exite a necessidade do uso de técnicas para um eficiente compartilhamento do canal de comunicação. Os clientes podem usar bcackchannel de várias formas, como por exemplo, para solicitar dados diretamente ao servidor, como no casos em que os dados requerem sigilo e portanto não podem aparecer no canal broadcast. A figura a seguir mostra G F E essa forma de combinação. D Servidor A B C AB BC EG Clientes... Fig 5.2 Forma de broadcast com push-based e pull-based 20
6 Arquiteturas de banco de dados de localização As duas abordagens mais comuns para arquiteturas dos bancos de dados de localização são os esquemas em duas camadas (two-tier schemes), similar ao modelo utilizado na telefonia celular, no qual a localização corrente para cada usuário em movimento é salvo em duas localizações da rede e o esquema hierárquico em que o espaço é hierarquicamente decomposto em sub-regiões. Nesta seção trataremos dessas abordagens. 6.1 Esquemas em duas camadas Nesse esquema, o banco de dados de localização local, chamada de Home Location Register (HLR), é associado com cada usuário móvel. O HLR é localizado em uma zona de rede pré-especificado para cada usuário. Ele armazena a posição corrente de cada usuário em movimento como parte do perfil do usuário. Os procedimentos de busca e atualização são bastantes simples. Para localizar o usuário x, a HLR de x é identificada e a consulta é realizada. Quando o usuário x se movimenta para uma nova zona, a HLR de x é contatada e atualizada para manter a nova localização. Como aprimoramento deste esquema, um Visitor Location Register (VLR) também é mantido em cada zona. O VLR da zona armazena as cópias dos perfis dos usuários que não são da sua área e estão atualmente localizados dentro de sua zona. Quando uma chamada estabelecida da zona i para o usuário x, a VLR da zona i é primeiramente consultada e somente se o usuário não for encontrado lá, a HLR de x é contatada. Quando x se movimenta da zona i para zona j, em adição à atualização da HLR de x, o registro de x é excluído da VLR da zona i e um novo registro para x é adicionado na VRL da zona j. 21
6.2 Esquemas hierárquicos O esquema de Localização Hieráquico estende o esquema em duas camada.mantendo o banco de localização em uma hierarquia. Nesta hierarquia, um banco de dados de localização contem as informações de localização de nível mais alto para todos os usuários localizados nos níveis inferiores. Normalmente esta hierarquia é uma estrutura em árvore. Neste caso, o banco de dados armazena em uma folha uma única zona (célula) e contem as entradas para todos os usuários registrados nesta zona. Em seu nós internos mantém informações sobre os usuários registrados no conjunto de zonas das sub-árvores. Para cada usuário móvel, estas informações são também um ponteiro para as entradas de nível mais baixo do banco de dados ou a localização atual do usuário. Os banco de dados são normalmente conectados por conexões da rede de sinalização inteligentes, por exemplo uma Common Channel Signaling (CSS). Por exemplo, em telefonia, o banco de dados pode ser colocados switches da rede. A figura a seguir apresenta alguns exemplos de armazenamento e busca nesta hierarquia. A figura a é um exemplo de registro de um usuário móvel na hierarquia. A figura b apresenta uma simulação de caminhamento na hierarquia para encontrar a localização de um usuário que recebeu uma chamada. A figura c apresenta o registro de uma nova localização de um cliente em movimento para fora de sua zona e a figura d apresenta a técnica de partição a qual busca reduzir o custo da busca na hierarquia. 22
a b chamada chamador movimento partições c Nova posição Usr x Usr x d Fig 6.1 Armazenamento e busca com localização hierárquica 7 O mercado de SGBD móveis Como atualmente as grandes corporações estão visando uma crescente necessidade de gerenciar melhor seus negócios através de manipulação de dados e transações cada vez mais distantes dos escritórios, os maiores fabricantes de software atentaram para o importante e crescente ramo da computação móvel e também entram nesse cenário propondo as mais diversas ferramentas para atender a essa demanda e também à demanda do usuário pessoal (que tem aumentado significativamente nos últimos anos com as novas 23
tecnologias em aparelhos celulares). A seguir apresentamos alguns dos principais produtos no mercado para banco de dados móveis. 7.1 Sybase Anywhere Studio O produto SQL Anywhere Studio da Syabase é um pacote que provê a gerência de dados e possui uma solução de banco de dados embutida chamada de Sybase UltraLite. Além do seu sincronismo com os SGBDs da Sybase, pode se comunicar com produtos de outros fabricantes. O SQL Anywhere Studio inclui dois poderosos sistemas de banco de dados relacionais, cada um visando uma classe diferente de usuário e de aplicações. O Adaptive Server Anywhere (ASA) oferece suporte a stored procedures, triggers, procedimentos de segurança e Java. Seu tamanho é limitado pela capacidade do host. Graças a presença de drivers ODBC e JDBC, os bancos de dados administrados pelo ASA podem ser acessados por qualquer programa desenvolvido nas modernas linguagens. Alternativamente, a opção Ultralite é um SGBD baseado em arquivos que suporta um subconjunto razoável de SQL, ocupa pouca memória e suporta desenvolvimento em C, C++ e Java. Possui ainda suporte integrado a sincronização com o MobiLink. Esta opção é endereçada a dispositivos com recursos restritos e também para aplicações que procuram minimizar a instalação no ciente de gerenciamento.apenas uma aplicação por vez pode acessar a base no Ultralite. O Studio oferece três opções de sincronização/replicação de dados: o MobiLink,o SQL Remote e o Replication Server. Este último é um sistema baseado em conexão para replicação entre um pequeno número de banco de dados. Normalmente usado com uma 24
conexão contínua, confiável e de alta velocidade, esta opção é inviável para ambientes onde as máquinas remotas sejam móveis ou apresentem desconexões freqüentes. Sendo assim, serão discutidas apenas as outras duas opções. A administração do banco de dados e os recursos requeridos pelo MobiLink e pelo SQL Remote são mínimos, fazendo com que estas opções sejam ideais para banco de dados móveis. Ambos podem ajudar com grande precisão a sincronização de cliente para o servidor (e vice-versa) através do desenvolvimento de scripts de sincronização de upload/download em SQL.Tais scripts são, na verdade, armazenados nos servidores de bancos de dados back-end e são executados tanto para cada tabela replicada quanto para eventos de sincronização globais (begin, end). O número de bases remotas que podem ser sincronizadas através do MobiLink ou do SQL Remote é limitado apenas pelo sistema gerenciador central. Esse número vai depender da quantidade de informação replicada, da freqüência da sincronização e do projeto da aplicação usada. Para as bases de dados corporativas, o MobiLink pode trabalhar com muitos servidores populares, incluindo Sybase Adaptive Server Enterprise, Oracle, Microsoft SQL Server e IBM DB2, além do próprio Adaptive Server Anywhere. Enquanto que a instalação do SQL Remote requer que o servidor tenha sua base gerenciada pelo ASA ou Sybase Adaptive Server Enterprise. Além de recursos como ferramentas de engenharia reversa, editor de consultas, depurador de stored procedures etc. O Studio oferece um número de outras ferramentas destinadas a fazê-lo uma solução tudo-em-um para o desenvolvimento de aplicações móveis. 25
A ferramenta Sybase Infomaker pode ser acessada para gerar relatórios on-the-fly (ou seja, gerados por demanda e destruídos após uso, não consumindo espaço em disco); A poderosa ferramenta de análise e design baseada em UML, o Power Designer, pode ser usada em conjunto com projetos de desenvolvimento em Java, XML, C++ e Visual Basic; O Sybase Central e o Interactive SQL, ferramentas para gerenciamento de bancos de dados, permitindo ao usuário efetuar design gráfico e manuseio de bases Ultralite e ASA, bem como os processos de sincronização Mobilink e SQL Remote. 7.2 Oracle Lite Mobile Server O produto Oracle Lite Móbile Server está construído sob o produto Oracle9i Application Server. Possui estrutura XML e suporta o desenvolvimento de aplicações que podem utilizar voz, troca de mensagens e o acesso sem fio. As aplicações móveis desconectadas podem acessar dados localmente. Muito poderoso, este sistema gerenciador de bancos de dados chega a questionar seu próprio nome Lite (leve). Oferece 100% de suporte a desenvolvimento em Java, através de drivers JDBC nativos e o suporte nativo a SQLJ [61] embutido e a stored procedures em Java, bem como a biblioteca Java Access Class (JAC) que provê uma interface orientada a objeto ao banco de dados. Programas feitos em qualquer ferramenta de desenvolvimento que ofereça suporte a ODBC (Visual Basic, C++, Delphi, etc.) também são suportados. Para aqueles que querem fazer uso das capacidades do SGBD objetorelacional Oracle9i Server, a Oracle inclui suporte para o OKAPI (Object Kernel API), que 26
pode ser chamada através de qualquer aplicação C/C++. O subconjunto de SQL do Oracle9i Lite perde pouco para a funcionalidade completa do PL/SQL. O Lite também inclui uma ferramenta que é o equivalente a uma versão móvel do SQLPlus, o Mobile SQL que acessa a base de dados via interfaces ODBC e OKAPI, suportando consultas elacionais e orientadas a objeto. Como foi dito antes, entre os SGBDs móveis, o Lite é o que oferece maior suporte a Java. Para construir uma stored procedure ou um gatilho (trigger) em Java, carregam-se as classes de Java através do comando loadjava e então uma chamada à classe é feita usando CREATE FUNCTION ou CREATE PROCEDURE, ambos comandos SQL. E as stored procedures em Java podem ser chamadas como qualquer outra, através da sintaxe padrão de SQL. O driver JDBC do Oracle9i Lite suporta totalmente as specificações do JDBC 1.22 e alguns dos recursos do JDBC 2.0 como, por exemplo, o suporte aos tipos de dados BLOB/CLOB. A sincronização é realizada através das ferramentas Mobile Server e Message Generator and Processor (MGP) que rodam no servidor. O Mobile Server faz uso do modelo publicar/inscrever (publish/subscribe), no qual uma ou mais publicações de bancos de dados podem ser definidas, consistindo de uma consulta usada para extrair dados da base do servidor. As inscrições ou assinaturas dos clientes são realizadas no Mobile Server e especificam que publicações (acompanhadas de parâmetros de filtragem) eles gostariam de sincronizar. Lógica de aplicação pode ser inserida no processo através da união de stored procedures de PL/SQL nos itens publicados. Todo esse trabalho de publicar/inscrever é gerenciado numa camada intermediária através do Mobile Server. O Mobile Server pode ser acessado pelo cliente móvel através do uso da classe de Java ResourceManager. Uma 27
API na linguagem C, MobileSync, proporciona suporte à conexão de sincronização direta do cliente para o servidor de banco de dados. Como foi descrito acima, o Mobile Server gerencia a sincronização de dados para e vindos do dispositivo móvel. Além disso, ele pode ser usado para a construção de aplicações para tais dispositivos. Aplicações desenvolvidas no Mobile Server têm seus dados atualizados sempre que ocorre uma sincronização. Este tipo de desenvolvimento é baseado na arquitetura Web-to-Go da Oracle, que essencialmente envolve uma aplicação web num servlet usando o Lite como o banco de dados cliente. O Mobile Client para Web- To-Go está disponível para dispositivos baseados em Win32. Clientes Mobile Sync estão disponíveis para clientes Win32, Windows CE, PalmOS e EPOC. Desenvolvedores de Windows CE também podem fazer uso da API com o ADOCE baseada em objetos para Oracle9i Lite. Além do Mobile Server, o outro componente principal do Oracle 9i Lite é o Mobile Development Kit, que dá ao desenvolvedor 4 opções de modelos de aplicação: Native (usam ODBC para acessar a base), Java (usam JDBC), Web-to-Go (apresenta um subconjunto das operações do Web-to-Go do servidor, é ideal para operações desconectadas) e Branch Office (que é uma versão multi-usuário da Web-to-Go, suportando até 32 diferentes usuários). 7.3 DB2 Everyplace O DB2 Everyplace é um banco de dados relacional com aproximadamente 150K. Pode ser utilizado como um banco de dados local quando seu host está desconectado ou 28
como um cliente acessando o servidor durante a conexão com a rede fixa. Possui sincronismo bi-direcional com os SGBDs corporativos. Tem como principais compontes: DB2 Everyplace DataBase e DB2 Everyplace Sync Server. Para uso no cliente, uma das funcionalidades do SGBD Everyplace é o Query-By- Example, uma interface gráfica para executar consultas e visualizar dados de uma tabela, permitindo rolar por entre as várias colunas e registros. Através do Query-By-Example, podese apagar, atualizar ou inserir registros, mas estas modificações só serão concretizadas após a sincronização dos dados com o Sync Server. O Sync Server é gerenciado na empresa através de uma ferramenta gráfica chamada Mobile Devices Administration Center, que facilita a replicação para um grupo de usuários com necessidades similares de sincronização de dados. Os usuários que receberão conjuntamente os dados de sincronização devem fazer uma assinatura num grupo de usuários, que podem ser feitas na ferramenta DataPropagator ou através do próprio JDBC. O processo de sincronização pode ocorrer de duas formas: usuários móveis submetem modificações em sua cópia local dos dados da fonte; usuários recebem modificações que foram feitas aos dados que estão no servidor da empresa desde a última sincronização. Quando os dados são modificados nos usuários móveis, o cliente aciona uma solicitação de atualização dos dados através do Sync Client, a solicitação é então autenticada e posta numa fila no sistema da camada intermediária. Importante notar que o usuário apenas pode modificar o subconjunto de dados do qual é assinante. Na camada intermediária, os dados são colocados numa tabela temporária, onde possíveis conflitos serão resolvidos. No servidor, o DataPropagator captura os dados e aplica as mudanças à 29
tabela no servidor. Para dados modificados no servidor, o procedimento é inverso, o DataPropagator que executa continuamente no sistema fonte, captura as modificações feitas à tabela e as aplica a uma tabela temporária no sistema da camada intermediária, os dados das modificações são colocados numa fila e capturados pelo Sync Client rodando no cliente móvel, que aplica as mudanças na base de dados local. 7.4 Microsoft SQL Server CE O Microsoft SQL Server CE é um banco de dados relacional para o desenvolvimento de aplicações para os equipamentos móveis. Pode ser utilizado como um banco de dados local quando seu host está desconectado ou como um cliente acessando o servidor durante a conexão com a rede fixa. Dois ambientes de desenvolvimento são suportados: o Visual Studio.NET e o embedded Visual Tools. Ambos fornecem um conjunto de APIs e um subconjunto da sintaxe de SQL feitos especificamente para trabalhar com o SQL Server CE. O SQL Server CE é implementado como um conjunto de DLLs que suportam as seguintes tecnologias de acesso a dados: ADOCE e ADOXCE; ADO.NET; OLE DB para SQL Server CE ADOCE é a API padrão da Microsoft para acessar e manipular registros de dados no sistema operacional Windows CE. ADOCE apresenta um subconjunto da biblioteca Win32 ADO (ActiveX Data Objects) da qual inclui os objetos Connection, Error, Recordset, Field e Fields. ADOCE será do interesse de qualquer um que pense em construir uma aplicação para Windows CE, já que ela é não só a API do SQL Server CE, mas também de todo o próprio sistema de arquivos nativo. Usando ADOCE, os bancos de dados podem ser 30
consultados (SELECT), editados (DELETE/INSERT) e modificado (usando comandos DML como CREATE/DROP/ALTER TABLE e CREATE/DROP INDEX). A ADOXCE é uma extensão da ADOCE com objetos adicionais de DDL (Data Defition Language) e segurança. ADO.NET é um aperfeiçoamento do ADO e é parte integrante do.net Compact Framework (um subconjunto da tecnologia.net suportado pelo Windows CE). O ADO.NET atende a uma variedade de necessidades de desenvolvimento, que incluem criação de aplicações no banco de dados do cliente e objetos de negócio da camada intermediária usados por aplicações, ferramentas, linguagens e browsers. OLE DB/CE é uma tecnologia de interface de dados de baixo-nível e proporciona maior capacidade de granularidade que o ADOCE e o ADOXCE e torna o acesso e manipulação dos dados mais rápida. Acessando as bases de dados do SQL Server CE via OLE DB/CE, as aplicações terão suporte às interfaces Data Source, Session, Command e Rowset, também um subconjunto do OLE DB. O SQL Server CE proporciona dois modos de sincronizar um banco de dados baseado em CE com um SQL Server corporativo. O primeiro método usa objetos Remote Data Access (RDA) para realizar uma sincronização push/pull entre o dispositivo móvel e o servidor, através do comando FILTER de SQL, permitindo que o desenvolvedor customize o fluxo de dados entre as bases. A segunda opção, conhecida como merge replication (replicação intercalada) usa o modelo publish/subscribe (publicar/inscrever) para sincronizar dados publicados para uma variedade de dispositivos previamente inscritos. Ambos RDA e replicação intercalada fazem uso do IIS (Internet Information Server) e são transportados via HTTP. No Visual Studio.NET, a aplicação deve chamar os métodos Synchronize e Dispose na instância do objeto a ser replicado (Replication object). Para sincronização de 31
aplicações no embedded Visual Tools, os métodos Initialize, Run e Terminate em sucessão devem ser chamados numa instância do Replication object. Quando o dispositivo móvel baseado em Windows CE não possui capacidade de conectividade, o Microsoft ActiveSync pode ser usado para se conectar com o ambiente servidor. Para desenvolver e depurar aplicações, o SQL Server CE requer a instalação do ActiveSync. A seguir temos um quadro comparativo dos principais produtos. Produto (versão atual) Sybase SQL Sistema Operacionais Windows Espaço em disco 3Mb-8Mb Ferramentas de sincronização MobiLink Tecnologias de desenvolvimento e gerenciamento Sybase Informaker; Anywhere 9x/Me/NT/2000/XP; SQL Remote PowerDesign; Studio 8.1 Windows CE/Pocket Sybase Central; PC; Interactive SQL UNIX/Solaris/Linux; PalmOS IBM DB2 Windows 175 Mb (servidor) DB2 Mobile Application Everyplace 9x/Me/NT/2000/XP; e 150Kb (cliente) Everyplace Builder; Mobile 8.1 Windows CE; Sync Srver; Devices Linux; Palm OS; DB2 Administration Symbiam 6 Everyplace Center; Sync Client DataPropagator Microsoft Windows 800Kb-3Mb; Remote Microsoft Visual SQL Server NT/2000/XP; 30Mb-45Mb DataAccess; Studio.NET CE Windows CE (desenvolvimento) Replicação ADOCE; ADOXCE, 32
Intercalada OLE, OLE.NET (Merge Replication) Oracle9i Lite Windows 200Mb (sevidor) Mobile Server; Mobile 5.0.1 9x/NT/2000; Message Developement Kit Windows CE; Palm Genarator and Os; EPOC Processor (MGP) Tabela 7.1 Quadro comparativo dos banco de dados 8 Conclusão O objetivo deste trabalho foi apresentar o papel dos Sistemas de Banco de Dados no ambiente da computação móvel, levando-se em conta os problemas desses ambientes e como os SGBDs podem contribuir e serem utilizados no sentido de expandir, cada vez mais, a utilização dos sistemas de informações, propiciando que em qualquer lugar e em qualquer hora o usuário móvel possa ter acesso à informação. O texto é apresentado buscando contribuir no entendimento da computação móvel, não se aprofundando nas questões de redes de computadores, sua infra-estrutura, protocolos e outros requisitos para esta área. A inserção de SGBD na computação móvel não é algo trivial. Os pressupostos para garantia da consistência e integridade dos dados, principal função dos SGBDs, não podem ser totalmente aplicado no ambiente móvel, uma vez que suas operações por dependerem de dois ambiente, em muitos momentos desconectados, não permitem que as transações de 33
banco de dados possam ser executadas como nos seus modelos centralizados ou distribuídos. Assim, constantes pesquisas se fazem necessárias no sentido de desenvolver novos modelos de transações que possam garantir as operações móveis, mantendo os requisitos básicos dos SGBDs em relação aos dados que armazenam. Diversas pesquisas em banco de dados para computação móvel acontecem vários centros de pesquisas científicas e são absorvidas pela indústria. Com essa evolução, cada vez mais estaremos mais acessíveis a utilização desses serviços. 34
9 Bibliografia www.oracle.com www.microsoft.com www.ibm.com www.acm.org www.ieee.org http://citeseer.nj.nec.com Design and evaluation of a replicated database for mobile system. S. Palazzo, A. Puliafito e M. Scarpa. 2000.ACM. A Hybrid Method for Concurrent Updates on Disconnected Databases in Mobile Computing Environments. Yin-Huei LOH Takahiro HARA Masahiko TSUKAMOTO Shojiro NISHIO. 2000.ACM. Banco de dados para um ambiente de computação móvel. Sérgio da Costa Cortez e Sérgio Lifschitz. 35