ODBC

O padrão ODBC (open database connectivity) foi desenvolvido pela Microsoft e acabou se tornando o padrão dominante no mercado de interfaces comum para acesso a bases de dados. Sua arquitetura em camadas permite aos aplicativos acessarem uma grande variedade de banco de dados utilizando a linguagem SQL.

Segundo Melo (1997, p.205) a arquitetura ODBC é composta por quatro

componentes básicos: a aplicação, o gerente de driver (driver manager), o driver e a fonte de dados (data source).

A aplicação consiste em um recurso de software que tem a função de

processar as chamadas das funções ODBC que cria meios padronizados para estabelecer uma conexão com o banco de dados, de modo que torne possível emitir instruções SQL ao SGBD.

O gerente de drivers é a parte intermediária da arquitetura, responsável pelo

recebimento das requisições emitidas pelas aplicações e pela determinação de qual driver será carregado para fazer a conexão com o SGBD apropriado. Uma vantagem significativa do gerente de driver é a capacidade de permitir que múltiplos drivers estejam ativos simultaneamente utilizando o nome da fonte de dados fornecido pela aplicação.

O driver2 por sua vez consiste em uma biblioteca de funções que processam as solicitações ODBC enviando instruções SQL especificas para cada fonte de dados. Quando uma aplicação faz uma requisição, o driver ODBC traduz a requisição para o formato apropriado do SGBD, servindo assim como um mediador entre os dois elementos.

A fonte de dados contém a definição de um driver ODBC utilizado pela

aplicação para acessar um SGBD específico. Trata-se dos dados propriamente ditos na abordagem ODBC e cada fonte de dados deve possuir um driver apropriado para que a intermediação possa ser estabelecida.

2 _{O driver corresponde a um conjunto de informações que fornece as instruções necessárias para que o} sistema operacional possa se comunicar com componentes de hardware específicos.

Figura 11: A arquitetura ODBC

3.3.4.2. DBI

A DBI (Database Interface) é uma interface de programação de aplicações (API) desenvolvida para a linguagem Perl3. Sua arquitetura foi projetada com o intuito de oferecer um conjunto de funções, variáveis e convenções que possam prover um mecanismo de comunicação de banco de dados consistente e independente da plataforma computacional utilizada pelo SGBD.

3 _{PERL (Practical Extraction and Report Language) é uma linguagem criada por Larry Wall,} inicialmente para sistemas Unix, e hoje roda em vários outros sistemas como Windows, Amiga, VMS, etc.

Essa interface (Descartes, 2000, p.1), se divide em dois grupos onde, o

primeiro, corresponde a própria arquitetura DBI, que implementa todas as funções de chamada de drivers, enquanto que o segundo, corresponde aos drivers responsáveis pela conexão ao seu SGBD específico.

Figura 12: A arquitetura DBI

Esta separação permite que a DBI suporte uma grande variedade de bancos de dados para utilização em ambientes de computação distribuída. Com isso a DBI é capaz de fornecer acesso múltiplo a diferentes tipos de bancos de dados, de uma forma transparente para os usuários. Com ela pode-se estabelecer conexões com bancos de dados Oracle, Informix, mSQL, Sybase, ou qualquer outra base de dados compatível, sem a necessidade de conhecer o mecanismo utilizado para efetuar esta tarefa.

Como benefício principal, a DBI dá às aplicações capacidade de conectar duas bases de dados de fabricantes diferentes, fazendo com que elas se comuniquem através do mesmo código-fonte escrito na linguagem Perl. Isso dá à aplicação capacidade de atualizar bases de dados através de uma forma bastante simples, facilitando assim o trabalho do programador.

3.3.4.3. JDBC

O JDBC (Java Database Conectivity) é uma interface desenvolvida pela Sun Corporation com a finalidade de estabelecer conexão entre bancos de dados SQL e aplicações desenvolvidas através da linguagem Java4. Com a JDBC os programadores podem criar aplicações Java capazes de acessar dados corporativos, independente da plataforma onde a aplicação está sendo executada.

A sua arquitetura, de acordo com Hamilton (1997, p.8) é composta por um conjunto de interfaces abstratas que permite ao programador estabelecer conexões a um determinado banco de dados, manipula-los através de instruções SQL e processar os resultados. Estas interfaces podem ser resumidas em quatro classes principais, a saber:

- java.sql.DriverManager: gerencia o carregamento de drivers para criar novas conexões de banco de dados;

- java.sql.Connection: representa uma conexão de um banco de dados específico;

- java.sql.Statement: funciona como um container para declaração ou execução de comandos SQL;

- java.sql.ResultSet: controla o acesso aos resultados das requisições.

4 _{A linguagem Java foi desenvolvida para ser uma linguagem independente de plataforma tornando-se} uma boa opção para criação de aplicações de acesso remoto a banco de dados.

Figura 13: A arquitetura JDBC

Com base nesta arquitetura, podemos perceber que a principal característica da JDBC é permitir um acesso genérico a banco de dados através de SQL. Ao mesmo tempo, a JDBC oferece uma interface padronizada para diferentes fontes de dados, cabendo ao programador apenas construir uma interface de usuário para facilitar a interação com o banco de dados.

Os tipos de drives suportados pela JDBC podem fornecer interfaces para SGBDs, tais como o Oracle, Sybase, Informix, além de outros que utilizam protocolos de acesso a banco de dados específicos, independentes ou não de protocolos de rede. Além desses, a JDBC, fornece conectividade para drivers ODBC.

3.3.4.4. BDE

O Borland Database Engine (BDE) é uma interface de acesso a banco de dados que contém um conjunto de funções e drivers que possibilitam às aplicações se comunicarem com uma variedade de sistemas de banco de Dados local ou remotamente. Sua arquitetura fornece uma forma única e transparente para a aplicação acessar os diferentes tipos de SGBDs.

Segundo Rudraraju (1995, p.1) o BDE utiliza drivers SQL IDAPI nativos

para fornecer conectividade aos diferente servidores de bancos de dados. Através da IDAPI (Integrated Database Application Program Interface), pode-se estabelecer conexões para SGBDs cliente/servidor Interbase, Oracle, Sybase, Informix, DB2 e SQL Server. Através desta interface, pode-se executar vários tipos de operações, tais como: criação de sessões, bancos de dados, tabelas, índices, campos, consultas, procedimentos e filtros.

Para concluir, o BDE se constitui em uma solução desenvolvida pela Borland Corporation para ser executada em plataformas Windows 9x/2000/ME e Windows NT. O BDE provê suporte a base de dados para aplicações desenvolvidas através de ambientes de desenvolvimento integrados, tais como o Delphi e C++ Builder.

3.3.5. Os Programas de Aplicação

Vimos que a arquitetura cliente/servidor divide o poder de processamento de um sistema computacional em sistemas cliente e servidor. Neste sentido, cada componente tem seu papel específico. A aplicação cliente fica encarregada de fazer a interface com o usuário, capturando os dados e exibindo informações, enquanto que a aplicação servidora, fornece recursos necessários para as aplicações clientes.

O programa de aplicação é o principal recurso que dá ao usuário a possibilidade de interagir com os sistemas de computação, principalmente nas tarefas que envolvem o acesso à banco de dados. Para prover esta funcionalidade, principalmente em sistemas cliente/servidor, as aplicações devem conter um conjunto de funções que possibilitem interação entre dois ou vários processos distribuídos em diferentes plataformas, de forma a cooperarem entre si para produzir os resultados desejados.

Para Melo (1997, p.60), “uma aplicação possui funções que podem ser

agrupadas em componentes para o processamento da lógica da interface do usuário, para o processamento da lógica de negócios, para a manipulação de dados e para os serviços de acesso aos dados”.

Figura 15: Interface de um programa de aplicação

As funções de interface de usuário correspondem a todas as atividades de interação entre o usuário e a máquina. Concentra recursos de controle de dispositivos de entrada e saída de dados, formatação de tela de apresentação, além de outras funções avançadas como verificação e validação de dados. As funções da lógica do negócio são aquelas que definem o verdadeiro propósito da aplicação, pois compreende toda a regra de

negócio e os processos administrativos de uma organização. As funções de gerência dos dados processam todas as operações de acesso e manipulação de dados fornecidos pelo usuário. Por fim, as funções de acesso a dados encarregam-se de fornecer recursos para acesso físico aos dados armazenados em um banco de dados.

Figura 16: Estrutura de uma aplicação

Com isso podemos perceber que um programa de aplicação tem uma estrutura claramente definida e que cada um de seus componentes cooperam entre si para executar a tarefa desejada pelo usuário. No que se refere à sua alocação, quando se tratava de ambientes centralizados, eles eram alocados em um único local. No entanto, a arquitetura cliente/servidor permitiu distribuir as funções entre os servidores e clientes da rede de forma a aumentar o desempenho dos sistemas de informação.

Com base nesta distribuição, a arquitetura cliente/servidor permitiu criar várias categorias de arquitetura, dividindo-a em camadas para tratar com diferentes configurações de seus componentes de aplicação. As principais arquiteturas abrangem dois tipos de modelos, a saber:

a) modelo de duas camadas: modelo no qual as aplicações cliente/servidor normalmente concentram as funções de interface de usuário e da lógica de negócio em um único componente. Esse componente fica alocado no cliente, enquanto que os dados e as funções de acesso a dados se concentram no servidor;

b) modelo de três camadas: neste modelo os dados e suas funções de acesso se concentram no servidor, enquanto que as regras de negócio e as aplicações são separadas em camadas distintas. Neste modelo as operações de acesso e manipulação de dados são executadas pela aplicação. O servidor só irá processa-los obedecendo às regras de negócio, que podem estar alocadas, ou na máquina servidora, ou na máquina cliente, ou em ambas as máquinas.

Através da arquitetura cliente/servidor, podemos perceber que a divisão das tarefas em camadas distintas resulta em um grande benefício para as aplicações. A distribuição de suas funções aproveitando de todos os recursos existentes, resulta em um melhor aproveitamento e um considerável ganho de performance, sem comprometer a integridade dos dados armazenados.

Para o desenvolvimento das aplicações, podemos encontrar atualmente uma grande variedade de ferramentas, ou linguagens, capazes de produzir aplicativos. Estas linguagens dispõem de todas as funções necessárias para criação de interfaces e implementação de funções de controle e de manipulação de dados. As ferramentas de desenvolvimento mais utilizadas atualmente são as linguagens orientadas a objetos e dirigidas por eventos, tendo como exemplo Java, Delphi, Powerbuilder, Visual Basic, SQL Windows, SmallTalk e Kylix.

3.3.6. Gerência de Transações

Um SGBD cliente/servidor implementa mecanismos de gerência de transações como um método destinado a assegurar que o banco de dados não sofra algum tipo de alteração que resulte em perda de dados ou resultados indesejados. O uso de transações em ambientes de banco de dados cliente/servidor se deve ao fato de que, muitos ambientes corporativos, em seus processos diários de trabalho, executam uma seqüência complexa de atividades que dependem constantemente da atualização dos seus dados para gerar resultados imediatos ao usuário da aplicação.

Segundo Silberschatz (1999, p.441) “uma transação é uma unidade lógica

de execução que acessa e, possivelmente, atualiza itens de dados”. Pode-se dizer que uma transação consiste em elemento importante para os SGBDs cliente/servidor, pois trata-se de um mecanismo que possibilita as aplicações em execução simultânea, atualizarem os dados de um banco de dados, sem comprometer a sua integridade.

Esse benefício só pôde ser obtido graças a um conjunto de operações, originadas de um estudo baseado em quatro regras fundamentais para gerenciamento de dados em ambientes multiusuário. Estas regras conhecidas como propriedades ACID, correspondem respectivamente a:

a) Atomicidade: define se todas as ações que representam a transação em um banco de dados serão aplicadas, ou caso contrário nenhuma delas será;

b) Consistência: assegura que um banco de dados ao sofrer uma alteração, mova seu estado de consistência de forma a garantir que os dados afetados não violem as regras de integridade;

c) Isolamento: define que uma transação não poderá ser afetada por outra, mesmo quando ambas são executadas simultâneamente;

d) Durabilidade: implica que os resultados de um processo de transação sejam permanentes, caso sejam concluídas com sucesso.

Um exemplo mais comum de um processo de transação (Hackathorn 1993,

p.61) é a transferência de fundos entre contas bancárias. Uma transação só deverá ser

completada se existirem fundos suficientes na conta original, verificando sempre se houve alguma alteração no banco de dados antes que ocorra a transferência. Se isto acontecer, a transação deverá ser abortada, evitando que o banco de dados seja alterado.

Figura 17: Representação de um processo de transação

Os SGBDs cliente/servidor realizam as transações através de comandos introduzidos na própria linguagem SQL conhecidos como Commit e Rollback. Estes comandos definem se as alterações serão concluídas com sucesso ou desfeitas quando há risco de inconsistência. Uma vez concluída a transação (através do comando commit), o SGBD muda o estado do banco de dados, tornando as alterações imediatamente visíveis para outros processos de transações. Caso o processo de transação não puder ser completado, a transação pode ser desfeita (através do comando rollback), fazendo que banco de dados retorne ao seu estado original.

Normalmente estas instruções são executadas através da aplicação, de acordo com o critério de processamento estabelecido pela lógica do negócio, ficando o SGBD responsável por toda à parte de gerência, podendo ou não utilizar mecanismos de controle, que muitas vezes são necessários em ambientes em que haja a execução de transações concorrentes.

3.3.7. Controle de Concorrência

Vimos que em um sistema de banco de dados cliente/servidor, ocorrerá situações em que vários itens de dados estarão sendo manipulados pelos usuários e quase que ao mesmo tempo. Isso significa dizer que, todas as atividades que ocorrem no banco de dados, estão em pleno processo de concorrência, podendo acontecer naquela mesma unidade de tempo, porém em fatias de tempo definidas.

O sistema de gerência de transações de um SGBD oferece mecanismos que torna possível realizar tarefas no banco de dados de forma isolada. No entanto, não poderão garantir a confiabilidade dos dados se o SGBD, não possuir meios para controlar o sincronismo entre as operações.

Segundo Kroenke (1999, p. 210), “o controle de concorrência consiste em

medidas que são tomadas para evitar que o trabalho do usuário não interfira no do outro”. Isso significa dizer que, se um SGBD cliente/servidor tiver que gerenciar atualizações em seu banco de dados, ele deverá possuir meios que garantam ao usuário, que o resultado se seu trabalho seja o mesmo, como se ele estivesse trabalhando isoladamente.

Existem atualmente dois mecanismos básicos de controle de concorrência utilizados pelos SGBDs. Estes mecanismos são baseados em princípios de bloqueios (deadlocks) ou de ordenação, de acordo com um critério estabelecido para a efetivação das ações de atualização de dados. Estes mecanismos são conhecidos como:

a) Controle de Concorrência Pessimista: funciona de maneira a bloquear o item de dado impedindo que outras transações executem atualizações no item bloqueado. Trata-se de um método que trabalha sempre na premissa de que sempre haverá possibilidade de conflito entre operações de transação, fazendo com que uma operação interfira na execução da atual. Com o método de bloqueio, torna-se possível garantir o isolamento, que é a principal propriedade das operações de transação. A desvantagem significativa estaria relacionada aos consideráveis atrasos que podem ocorrer, e que às vezes podem ser até desnecessários;

b) Controle de Concorrência Otimista: trata-se de uma técnica que se concentra em realizar alterações, baseados na premissa da não-existência de conflitos. Cada processo de transação age sem comprometer a execução de outra. Neste mecanismo toda a avaliação é feita no momento em que o item de dado está sendo atualizado. Neste período, é feita a verificação das demais transações para ver se algum dado foi alterado no período em que a transação foi iniciada. Este mecanismo evita a possibilidade de usar métodos de bloqueio durante o processo. A desvantagem desta técnica é que, em algum caso de falha, toda a operação de transação deverá reinicializada para assegurar a integridade dos dados.

3.3.8. Segurança e Administração

Segundo Silberschatz (1999, p.13), “uma das principais razões que

motivaram o uso de SGBDs é o controle centralizado, tanto dos dados, quanto dos programas de acesso a esses dados”. Isso convêm afirmar que o controle centralizado de um sistema de banco de dados, em um ambiente cliente/servidor, consiste em um grande benefício para a segurança das informações. No entanto, ao fazer uma analogia com os sistemas de informação atuais, observamos que as empresas disponibilizam seus dados a vários tipos de usuários, dentro ou fora do seu ambiente físico.

Por essa razão tem-se por definido que, para garantir a segurança do próprio banco de dados da empresa, não se deve levar em conta apenas o uso das ferramentas de administração incorporadas nos SGBDs. Deve-se considerar também o fator humano, que determina qual pessoa tem o perfil necessário para administrar os recursos primários (banco de dados) e secundários (SGBD e ferramentas relacionadas) do sistema.

O Administrador de Banco de Dados (DBA), é a pessoa que possui a competência técnica para gerenciar todo o sistema de banco de dados de uma organização. Suas principais funções envolvem um conjunto de atividades que partem, desde a definição da estrutura e do conteúdo do banco de dados, até atividades relacionadas à administração dos componentes principais do sistema. Dentre esses componentes são mencionados os servidores, estruturas de armazenamento e métodos de acesso, mecanismos de medição de desempenho, backup e recuperação de dados, administração de usuários e restrições de integridade.

Outra tarefa importante do DBA é também servir de elo de ligação entre os bancos de dados e os usuários. O DBA define os critérios de autorização através de mecanismos que permitam criar contas de usuário, implementando o critério de segurança apropriado. Além disso, o DBA pode fornecer aos analistas e programadores, todas as informações necessárias para viabilizar o desenvolvimento de aplicações de banco de dados específicas, que serão utilizadas pelos usuários finais.

Com relação à tecnologia utilizada para resolver as questões de segurança ao nível de usuário, o DBA pode através do SGBD, implementar mecanismos de segurança baseados em esquemas de login e senha, e também em níveis de privilégios.

Os mecanismos de controle de acesso baseados em login e senha, permitem aos SGBDs, não só garantir ou restringir o acesso dos usuários, como também registrar todas as operações a partir do período em que o usuário acessa o banco de dados até o momento em que ele encerra suas atividades.

Os níveis de privilégios por sua vez, permitem restringir o acesso a determinado banco de dados a um grupo restrito de usuários. Uma vez definido qual banco de dados poderá ser acessado, poderemos também definir quais tipos de operações poderão ser realizadas pelos usuários sobre seus objetos. Vários produtos de SGBD que utilizam SQL implementam métodos conhecidos como GRANT e REVOKE para garantia e a revogação dos níveis de privilégios dos usuários.

Figura 19: Definindo privilégios no SQL Server 6.5

Em um ambiente cliente/servidor, pudemos observar que as tecnologias de SGBDs são capazes de garantir a segurança dos dados contra usuários não autorizados. No que se refere às questões de hardware e software, o controle centralizado dos dados também torna possível reforçar os níveis de segurança. O DBA pode em caso de pane ou perda de dados durante alguma operação complexa, utilizar mecanismos de backup e recuperação adequados para garantir a restauração do banco de dados.