Um SGBD - Sistema de Gerenciamento de Banco de Dados é uma coleção de programas que permitem ao usuário
definir, construir e manipular Bases de Dados para as mais diversas finalidades.
Um conceito que deverá ficar bastante claro inicialmente é o que envolve a separação clara entre os Gerenciadores de
Base de Dados dos Gerenciadores de Arquivo.
Sistemas baseados em "Banco de Dados" baseados em Btrieve e dBase (Fox e Clipper), podem no máximo simular as
características típicas de um ambiente de Banco de Dados.
A linguagens Delphi (utiliza opcionalmente o padrão dBase)
e o Visual Basic (que utiliza o Access), recomendam a utilização de Banco de Dados reais, porém utilizam àqueles "Banco de
Dados" que possuem algumas características de Bancos de Dados, mas possuem características típicas de Gerenciadores
de Arquivo.
Vamos definir algumas regras básicas e claras para um sistema de manipulação de dados ser considerado um SGBD.
Fica implícito que se ao menos uma das características abaixo não estiver presente no nosso "candidato" a SGBD, este
poderá ser um Gerenciador de Arquivo de altíssima qualidade, "quase" um
SGBD, mas não um SGBD.
Regra 1: Auto-Contenção
- Um SGBD não contém apenas os dados em si, mas armazena completamente toda a
descrição dos dados, seus relacionamentos e formas de acesso. Normalmente esta regra é chamada de Meta-Base de
Dados. Em um GA, em algum momento ao menos, os programas aplicativos declaram estruturas (algo que ocorre
tipicamente em C, COBOL e BASIC), ou geram os relacionamentos entre os arquivos (típicos do ambiente xBase). Por
exemplo, quando você é obrigado a definir a forma do registro em seu programa, você não está lidando com um SGBD.
Regra 2: Independência dos Dados
- Quando as aplicações estiverem realmente imunes a mudanças na estrutura de
armazenamento ou na estratégia de acesso aos dados, podemos dizer que esta regra foi atingida. Portanto, nenhuma
definição dos dados deverá estar contida nos programas da aplicação. Quando você resolve criar uma nova forma de
acesso, um novo índice, se precisar alterar o código de seu aplicativo, você não está lidando com um SGBD.
Regra 3: Abstração dos Dados
- Em um SGBD real é fornecida ao usuário somente uma representação conceitual dos
dados, o que não inclui maiores detalhes sobre sua forma de armazenamento real. O chamado Modelo de Dados é um
tipo de abstração utilizada para fornecer esta representação conceitual. Neste modelo, um esquema das tabelas, seus
relacionamentos e suas chaves de acesso são exibidas ao usuário, porém nada é afirmado sobre a criação dos índices, ou
como serão mantidos, ou qual a relação existente entre as tabelas que deverá ser mantida íntegra. Assim se você desejar
inserir um pedido em um cliente inexistente e esta entrada não for automaticamente rejeitada, você não está lidando com
um SGBD.
Regra 4: Visões
- Um SGBD deve permitir que cada usuário visualize os dados de forma diferente daquela existente
previamente no Banco de Dados. Uma visão consiste de um subconjunto de dados do Banco de Dados, necessariamente
derivados dos existentes no Banco de Dados, porém estes não deverão estar
explicitamente armazenados. Portanto, toda vez que você é obrigado a replicar uma estrutura, para fins de acesso de
forma diferenciada por outros aplicativos, você não está lidando com um SGBD.
Regra 5: Transações
- Um SGBD deve gerenciar completamente a integridade referencial definida em seu esquema, sem
precisar em tempo algum, do auxílio do programa aplicativo. Desta forma exige-se que o banco de dados tenha ao menos
uma instrução que permita a gravação de uma série modificações simultâneas e uma instrução capaz de cancelar um série
modificações. Por exemplo, imaginemos que estejamos cadastrando um pedido para um cliente, que este deseje reservar
5 itens de nosso estoque, que estão disponíveis e portanto são reservados, porém existe um bloqueio financeiro
(duplicatas em atraso) que impede a venda. A transação deverá ser desfeita com apenas uma instrução ao Banco de
Dados, sem qualquer modificações suplementares nos dados. Caso você se obrigue a corrigir as reservas, através de
acessos complentares, você não está lidando com um SGBD.
Regra 6: Acesso Automático
- Em um Gerenciador de Arquivo uma situação típica é o chamado Dead-Lock, o abraço mortal. Esta situação
indesejável pode ocorrer toda vez que um usuário travou um registro em uma tabela e seu próximo passo será travar um
registro em uma tabela relacionada à primeira, porém se este registro estiver previamente travado por outro usuário, o
primeiro usuário ficará paralisado, pois, estará esperando o segundo usuário liberar o registro em uso, para que então
possa travá-lo e prosseguir sua tarefa. Se por hipótese o segundo usuário necessitar travar o registro travado pelo
primeiro usuário, afirmamos que ocorreu um abraço mortal, pois cada usuário travou um registro e precisa travar um
outro, justamente o registro anteriormente travado pelo outro! Imaginemos um caso onde o responsável pelos pedidos
acabou de travar o Registro Item de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar uma
nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualização de pendências na Tabela de Itens, e para tanto, previamente este segundo usuário travou a Tabela de Produtos, temos a ocorrência do abraço mortal. Se a
responsabilidade de evitar esta ocorrência for responsabilidade da aplicação, você não está lidando com um SGBD.
Conclusão:
Um SGBD deve obedecer INTEGRALMENTE as seis regras acima. Em caso contrário estaremos diante de
um GA ou de um "quase" SGBD.
Considerações Finais
Atualmente, existe uma tendência de mercado em se dizer que qualquer problema será resolvido, caso a empresa adquira
um Banco de Dados.
Naturalmente, em um ambiente com acesso constante ao Banco de Dados (acesso concorrente, obviamente), onde a segurança seja de vital importância e que o desempenho da aplicação escrita estiver comprometendo
a empresa, considerando-se logicamente uma aplicação bem escrita, sem dúvida a aquisição de um Banco de Dados
poderá ser o primeiro passo na solução do problema.
Analogamente ao que ocorreu com o aparecimento das primeiras linguagens de programação voltadas ao Windows, onde estas foram apresentadas como capazes de alavancar os negócios da empresa, e no geral causaram mais frustração
do que solução, a aquisição do Banco de Dados, pode gerar o mesmo tipo de problema. É fundamental que a empresa candidata a utilizar um Banco de Dados, normatize-se totalmente, pois soluções “quebra- galho”, típicas do ambiente que dispõe de um Gerenciador de Arquivo, tendem a ser impossíveis em um ambiente
estruturado sobre o Banco de Dados.
Portanto, sob pena de se realizar um grande investimento, e não se colher fruto
algum, é muito conveniente, que a empresa antes de adquirir um Banco de Dados, passe por um processo de adaptação, preferencialmente contando com pessoal especializado, geralmente consultores, que não tenham qualquer ligação com
fabricantes de Bancos de Dados.
