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.