Modelo Cliente - Servidor

“... foi simplesmente espetacular o progresso que os computadores conheceram em um curto período de tempo. Nas duas primeiras décadas de sua existência, os sistemas computacionais eram acondicionados, geralmente, em uma grande sala com paredes de vidro(...). Uma empresa de médio porte ou uma universidade contava apenas com um ou dois computadores... ” (Tanenbaun S. Andrew, Redes de computadores)

Num primeiro momento, desenvolver aplicativos de bancos de dados para PC era uma abordagem de um único processo. Tanto o programa quanto os arquivos de “banco de dados” ficavam no mesmo computador e todo o esforço do desenvolvimento era concentrado na aplicação, ou seja, todo o tratamento, desde a entrada até a gravação física do registro, era implementado no aplicativo, como por exemplo: construção da interface gráfica (telas), as validações (checkes) e os algoritmos de classificação, busca, gravação, leitura e indexação.

Com o surgimento das redes, programadores audazes moveram os arquivos de dados para um servidor de arquivos, visando desta forma viabilizar o acesso de múltiplos usuários a mesma base de dados. Agora vários computadores poderiam compartilhar das informações contidas no banco de dados. Contudo, esses computadores teriam que possuir o software aplicativo (que continha todo o mecanismo de manipulação de dados descrito acima) instalado, porém os arquivos de bancos de dados agora estavam disponíveis para múltiplos usuários acessa-los simultaneamente. Até hoje se usa este modelo, e alguns sistemas que trabalham com banco de dados locais (Paradox, access, Dbase e ect..) são configurados desta forma, o modelo de servidores de arquivos.
Esta estratégia, amplamente difundida no passado, embora tenha trazido alguma inovação, muito mais no aspecto físico do que lógico, não se consolodou como um modelo definitivo, a partir do momento que trouxe mais demandas do que soluções. Como assim? Imagine a seguinte situação:


um jantar, ou ceia comunitária onde os convidados deveriam, cada um, trazer parte da comida e bebida, deposita-la numa única mesa e, ao mesmo tempo, outros convidados estariam se servindo de alimentos que já estariam na mesa. Podemos imaginar, a partir deste exemplo, as dificuldades que os participantes desta ceia deveriam estar enfrentando. Cada vez maior seria o problema quanto mais pessoas chegassem para participar da ceia, em pouco tempo o caos estaria estabelecido. È óbvio que sem uma forma de gerenciamento esta configuração fatalmente será insustentável. Os sistemas gerenciadores de banco de dados surgem com afinalidade de atender justamente esta necesidade.

No armazenamanto de dados flle-server, toda a inteligência do “banco” reside no software cliente. Embora que o arquivo de dados resida no servidor remoto, este servidor não tem inteligência para gerenciar esses dados.
No modelo cliente-servidor o banco de dados não é apenas um arquivo, ou melhor, não é uma pasta contendo vários arquivos(que seriam as tabelas e os índices). Mas sim um programa, um sistema que controla e gerencia o banco, onde reside toda a inteligência do banco de dados. Este programa prove um serviço de acesso, armazenamento e manipulação de dados. Podemos concluir então que: se existe processamento no banco agora, eu posso pegar os processos que antes estavam todos codificados no sotware cliente, e dividi-los com o programa de banco de dados.

O modelo client-server reduz significantemente o tráfego de rede, também provê uma melhor integridade no banco e o torna mais poderoso, já que todo o gerenciamento do software fica em único lugar.

Continua em ... Back-End

Artigo completo (View Full Post)

Arquiterura Cliente-Servidor: Back-end

O conceito de máquinas em níveis tem como proposta fazer com que o usuário final enxergue um sistema computacional somente através do aplicativo. Este conceito está tão incorporado em nossa cultura que, hoje, para uma pessoa utilizar um aplicativo, editor de texto por exemplo, e imprimir o resultado de um trabalho, não demanda da parte dela nenhum conhecimento sobre informática.

No modelo cliente servidor esse conceito também esta presente. Ou seja, concebemos uma aplicação de banco de dados como um único sistema. E devemos faze-lo de maneira que o usuário o enxergue desta forma. Entretanto, essa aplicação na verdade é um sistema composto por dois programas. Um aplicativo que é executado pela máquina que requisita o serviço, os chamados Cliente(Front-end), e o back-end que é a sua base de dados fica num servidor. Todavia, devemos entender, agora, “base de dados” não mais como um arquivo, passivo, mas como um sistema, programável, que gerencia o acesso, a manutenção, a atualização e a integridade da base de dados. Logo, podemos definir da seguinte forma:

• Um banco de dados é uma coleção de tabelas relacionadas, onde cada tabela armazena um específico conjunto de dados. Ele também é um container para outros objetos que o auxiliam no gerenciamento destes dados.

A maior parte do esforço do desenvolvimento, cerca de 75%, fica no back-end. No SGBD são definidos e programados todos os processos que serão executados no servidor.
Para uma explicação mais clara, seria interessante comparamos e enfatizarmos a separação entre os Servidores de Banco de Dados(SGBDs) dos Servidores de Arquivo(banco de dados local).

SGBD x Servidor de Arquivos

Para uma rápida compreenção, podemos explicar os SGBDs a partir dos já conhecidos bancos de dados locais. Programas como Paradox, Visual dBase e Access que geralmente operam no modelo flle-server(Servidor de arquivos). Como isso funciona?

Em banco de dados flle-server, toda a inteligência do banco reside no software cliente. Embora que o banco de dados resida no servidor remoto, este servidor não tem inteligência para gerenciar o banco. Quais são as implicações que isso pode trazer?
Por exemplo: Quando você quiser realizar uma operação nas tabelas do banco, tudo é copiado para a memória do computador client que está requisitando tal operação. Vejamos, se você quiser executar uma query numa tabela de Clientes que conténha 2.000.000 de registros:

SELECT NOME
FROM CLIENTES
WHERE ID_CLIENTE =1;

Temos como objetivo que seja retornado apenas a coluna NOME do cliente 1, porém no modelo servidor de arquivos toda a tabela CLIENTES, ou seja, todas as colunas e todos os 2.000.000 registros serão transportados para a memória da máquina cliente, e, só então, lá será executada a filtragem.

No modelo client-server o banco de dados não é apenas um arquivo, ou melhor, não é uma pasta contendo vários arquivos(que seriam as tabelas e os índices). Mas sim um programa, um sistema que controla e gerencia o banco, onde reside toda a inteligência do banco de dados. Este programa prove um serviço de acesso, armazenamento e manipulação de dados. Como assim?
No modelo cliente servidor o mesmo exemplo mostrado anteriormente transportaria apenas a coluna NOME do cliente, cujo o código seja igual a 1, para o software cliente . É importante destacarmos que todo o processamento recorrente da nossa requisição acontece no servidor. Ora, podemos concluir então que: se existe processamento no banco agora, eu posso pegar os processos que antes estavam todos codificados no sotware cliente, e dividi-los com o programa de banco de dados.
O modelo client-server reduz significantemente o tráfego de rede. Isto provê uma melhor integridade no banco e o torna mais poderoso, já que todo o gerenciamento do software fica em único lugar. No modelo file-server cada máquina client precisará ser um tanto poderosa. Isto porque a parte inteligente(que gerencia e controla o banco) estará nos clients. Portanto, essas máquinas serão bastante exigidas no que tange a processamento e armazenamento temporário de informação. Em contrapartida no modelo client-server somente a máquina server precisará ser poderosa.

Objetos de DB

Domains (Domínios):
 Tipo de dados, pode ser definido pelo programador. Subdividem-se em:
 Domínios simples e Domínios compostos. Os Domínios quando bem aplicados funcionam
 como uma forma de desacopalmento do seu modelo (físico) de dados em relação ao mundo real.
 Ao fazer uso desse recurso, você centraliza regras sobre os dados, as quais deverão garantir
 que não seja “inputado” lixo, de maneira que seu SGBD fique mais organizado, conseqüentemente
 reduzindo drasticamente a possibilidade do seu banco de dados, com o decorrer do tempo, se tornar um “Bando de dados”. 

Tables (Tabelas):
 Objeto para armazenamento de dados. É uma estrutura homogênia, que armazena os
 dados sob uma referência coluna/Linha.

Indexes (Índices):
 Como o nome já indica, indexa os dados crescente ou decrescentemente. Basicamente
 você pode entender índices como uma tabela, uma meta tabela,  que armazena o
 endereço físico do dado. Alguns definem como: Lista com ponteiros em tabela,
 usado para prover performance.

Constraints:
    A) Definem relacionamento entre as Tabelas. Verificador de integridade de dados.
    B) Checks :  Garantem que somente valores permitidos sejam armazenados (Regras de negócio).

Views (Visões):
 Uma consulta que regularmente você precisa fazer, pode ser definida em forma de
 uma View. A partir de então vc poderá consultar diretamente, referenciando em
 código a View criada. Uma consulta cujo o código demande um número exagerado de
 código pode ser fatorada em Views.

Stored Procedures (Procedimentos Armazenados):
 Código armazenado no banco. São procedimentos que serão executados ad-hoc,
 ou vinculados a uma Trigger.

Generators/Sequences:  Contadores de auto-incremento.

Triggeers (Gatilhos):
 Código executado em resposta a algum evento sobre uma tabela no banco.
 Usado para manter integridade nos dados e segurança.

Role: Papéis contendo privilégios que serão atribuídos aos usuários. Segurança.

Artigo completo (View Full Post)