Programação de Banco de Dados - parte 2

Este é o segundo artigo relacionado com programação de Banco de Dados. No primeiro artigo o enfoque foi explicar as tecnologias relacionadas ao acesso a dados. Neste segundo artigo voltaremos nossa atenção para a arquitetura cliente/servidor.

por Renato Mattos

Este é o segundo artigo relacionado com programação de Banco de Dados. No primeiro artigo o enfoque foi explicar as tecnologias relacionadas ao acesso a dados. Neste segundo artigo voltaremos nossa atenção para a arquitetura cliente/servidor. Se você está desenvolvendo aplicativos de banco de dados para executar em uma rede local, a arquitetura cliente/servidor é adequada para esse trabalho.

Arquitetura Cliente/Servidor.

A arquitetura cliente/servidor possui uma premissa simples: computadores diferentes executam tarefas diferentes e cada computador pode se otimizado para uma tarefa em particular.Em um ambiente de rede, o SGBD fica em uma única máquina.Contudo, muitos aplicativos acessam o banco de dados e todos os clientes fazem solicitações ao mesmo banco de dados.O programa que aceita e trabalha essas solicitações é o SGBD, e a máquina na qual o SGBD está sendo executado é o servidor de dados.

O Modelo de Duas Camadas.

A primeira camada de um aplicativo cliente/servidor é a camada cliente que é executada no cliente.Essa camada contém o aplicativo que interagem com o usuário e usualmente são aplicativos em VB.Você também pode construir camadas clientes que são executadas em um navegador - são páginas Web que possuem controles semelhantes ao controles básicos do VB e possibilitam ao usuário interagir com o banco de dados.

O aplicativo cliente solicita dados de um banco de dados e exibe-os em um ou mais formulários.Um vez que os dados estão no computador cliente, seu aplicativo pode processa-los.O computador cliente é inteiramente capaz de manipular os dados localmente, sem que o servidor se envolva no processo.Se o usuário edita os campos, o aplicativo pode atualizar o banco de dados sem problemas.A comunicação entre o cliente e o servidor ocorre por meio do ADO, que torna mais simples o processo de manipulação dos dados.

A segunda camada é servidor de bando de dados, ou SGBD. Essa camada manipula um objeto muito complexo, o banco de dados , e oferece uma visão simplificada deste por meio do OLE DB e ADO.O trabalho do servidor é extrair os dados solicitados de uma tabela e fornece-los ao cliente na forma de um cursor, ou seja, ele simplesmente transmite um cursor ao cliente para que este processe a com termos como: duas camadas, três camadas.

Na segunda camada é possível através de procedimentos armazenados executar as operações no lado do SGBD, pela divisão do trabalho entre cliente e servidores, permitimos que cada aplicativo faça o melhor. O SGBD é executados em uma das máquinas mais rápidas da rede, os clientes não precisam ser poderosos.

No modelo de 2 camadas existe a possibilidade de deixar do lado do Servidor parte ou toda a regra do negócio.Essa metodologia foi e ainda é muito usado. Para se dizer que se trabalha em 2 camadas a camada cliente possui um software e a camada servidor também é um software, neste caso software conversa com software.No caso do Access , mesmo colocando em uma máquina na rede sendo o servidor e os aplicativos acessando o Access não seria modelo de 2 camadas pois o Access não é um SGBD , não existe a comunicação software x software. Quem efetua essa comunicação é o driver.O aplicativo cliente efetua a solicitação e o "driver" que se encarrega de atender. O SQL Server, My SQL , Oracle são SGBD.

No entanto muitos consideram o Access um SGBD pelo fato de trazer algumas características de um SGBD como controle de concorrência, mas ele não é um banco cliente/servidor.

O MODELO DE 3 CAMADAS

O modelo de 3 camadas possui uma arquitetura muito eficiente para aplicativos de bando de dados, mas nem sempre é a melhor escolha.Muitos programadores desenvolvem aplicativos de duas camadas que são executados em pequenas redes.

Em 2 camadas o cliente conversa diretamente com o servidor. O papel do servidor do banco é acessar e atualizar os dados. O resto é deixado para o cliente.Se encontra aplicativo onde é deixado toda a regra do negocio do lado do cliente, toda a regra do negócio do lado do servidor ou então dividido entre cliente e servidor.

Vamos analisar essas 3 possibilidades de implementação em 2 camadas.

• Regra do negócio do lado do cliente: uma vez que regras do negócio refletem práticas comerciais, elas mudam com muita freqüência. Novas regras são introduzidas, as existentes são revisadas e isso significa que o código que as implementam está sujeito a alterações freqüentes. Se implementar regras do negócio no cliente , você deve distribuir os novos executáveis para as estações de trabalho e certificar-se de que todos os usuários da rede estão usando a última versão do software cliente.

• Regra do negócio do lado do servidor: se as regras do negócio são implementadas no servidor, você não precisa redistribuir o aplicativo, mas atribui uma carga adicional ao servidor.

• Regra do negócio tanto no servidor com no cliente: desta forma divide o processamento entre cliente e servidor, mas no entanto fica segmentado a regra do negócio trazendo assim maior dificuldade em atualizações.

Isso nos leva, naturalmente para introdução de uma 3 camada, a camada intermediaria.A camada intermediaria é um objeto que se situa entre o aplicativo cliente e o servidor.Trata-se de uma classe ou várias classes que expõe vários métodos e isola o cliente do servidor.

A principal vantagem da camada intermediaria é que ela isola o cliente do servidor. O cliente já não acessa o bando de dados.Em vez disso, ele chama os métodos expostos pelos objetos na camada intermediaria.Um aplicativo cliente eventualmente adicionará um novo cliente ao banco, mesmo essa simples operação requer alguma validação.Um aplicativo bem estruturado implementa essas operações na camada intermediária. O aplicativo cliente não precisa saber como adicionar um novo cliente, basta chamar a função que efetua o cadastro passando os valores como argumentos.

O modelo de 3 camadas divide os componentes de um aplicativo em 3 categorias:

• Camada de Apresentação: Este programa é executado no cliente e interage com o usuário.Você usualmente desenvolvera aplicativos para a camada de apresentação e esses aplicativos serão chamados freqüentemente de serviços do usuário.

• Camada de Aplicação: conhecida como camada de regras do negócio, está camada contém a lógica do aplicativo.Isso simplifica o acesso do cliente ao banco de dados por meio do isolamento do serviço de usuários do bando de dados.Essa camada é projetada antes que você comece a codificar o aplicativo cliente.

• Camada de Dados: esta camada esta no servidor de bando de dados que atende as solicitações feitas pelos clientes.O servidor do banco de dados deve atualiza-lo e ao mesmo tempo proteger sua integridade.

É comum encontrar modelos de 3 camadas sendo uma camada cliente, um servidor Web e um servidor de banco de dados, ficando a regra do negócio divida ou centralizada em uma das camadas.Dessa forma surgiu o modelo de 4 camadas onde teria o lado cliente, servidor Web, servidor de banco de dados e servidor com a regra do negócio.Esse modelo não é ainda muito aplicado e pouco necessário, até mesmo o de 3 camadas com servidor de regras do negócio é pouco aplicado e necessário.

O ACCESS E APLICATIVOS CLIENTE/SERVIDOR

O Access não é um servidor de bando de dados.Quando você contata o Access e abre uma tabela, a tabela inteira é carregada para a memória do computador cliente.Se houver 5 usuários na rede e todos estiverem acessando a mesma informação, então cinco copias das mesmas tabelas estarão nos clientes.

Uma das diferenças mais importantes entre o Access e o SQL Server é o modo como eles lidam com a concorrência. O SQL Server mantém uma única copia dos dados.Como muitos clientes precisam passar pelo SGBD, o SQL Server sabe quando um registro esta sendo editado e impede que outros usuários consigam excluir ou até mesmo ler o mesmo registro.O Access deve comparar as alterações efetuadas no cliente para o original e depois decidir se outros usuários podem ou não acessar uma linha.Se um usuário abre uma tabela e seleciona uma linha para editar, nenhum outro usuário pode editar a mesma linha..Dessa forma a linha permanecerá bloqueada indefinidamente.A medida que o numero de usuários aumenta, a sobrecarga torna-se insuportável e então é hora de trocar o bando para SQL Server.

O Access 2000 pode ser usado para desenvolver aplicativos cliente/servidor, mas este recurso do Access é baseado na tecnologia do SQL Server.Através do componente MSDE que é um mecanismo de dados cliente/sevidor. O MSDE é totalmente compatível com o SQL Sever; ele se baseia-se no mesmo mecanismo de dados do SQL Server, porém é indicado para pequenos grupos de trabalho.Você pode usar o MSDE para desenvolver aplicativos e posteriormente se necessário migrar para SQL Server alterando somente as informações de conexão.

Antes de prosseguirmos falaremos sobre a linguagem SQL mas no próximo artigo.