Este conceito, denominado de dicionário
de dados, visa substituir a utilização dos scripts de atualização das
estruturas do banco de dados no cliente por uma solução mais eficiente. Essa
solução irá nos garantir que a estrutura atual do banco está de acordo com os
dados do dicionário, independente de quantas e quais versões o cliente deixou de
atualizar.
O gerenciamento de scripts que realizam a atualização do banco de dados no cliente, em geral, gera problemas.
Primeiramente por que constantemente temos scripts que por algum motivo não foram executados e ocasionam erros no cliente, os quais geralmente conseguimos identificar pela mensagem e dizem respeito à falta de um campo que o script não criou ou atualizou.
Outra dificuldade ocorre por que em algum momento o cliente pode ter perdido algumas atualizações do sistema e quando se tenta executar o script da versão X até a Y com frequência temos problemas.
Além disso, é difícil efetuar o controle de versão desses scripts, pois não temos a possibilidade de rollback a menos que criemos um script separado para isso, sem contar que esses arquivos, com passar do tempo, vão ficando cada vez maiores.
Como resolver esse problema? Qual seria a melhor solução para isso? Uma alternativa de resolução para essa questão envolve a utilização de dicionários de dados, que serão explicados a seguir.
Dicionários e o banco de dados
O dicionário, nesse contexto, é uma estrutura de dados que contém a representação dos elementos do banco de dados. No contexto dos SGDBs, esses dicionários representam a estrutura do nosso banco, contendo informações como descrição dos objetos, restrições de integridade, stored procedures, triggers, índices, chaves e validações.
O uso de dicionários para representação da base de dados traz algumas vantagens que incluem maior facilidade para atualização do banco e para integração deste com a aplicação, que consegue mais facilmente reconhecer a estrutura das tabelas e exibir uma interface adequada para o usuário.
Neste caso teremos um arquivo com todas as definições do banco de dados e esse arquivo vai ser definido manualmente por nós, então podemos acrescentar nele algumas informações que poderão ser importadas e aproveitadas na aplicação.
Uma dessas informações cuja definição podemos otimizar é o caption da coluna, que geralmente atribuímos manualmente a cada label nas telas do sistema.
Utilizando a estratégia do dicionário podemos importar esse caption diretamente do arquivo de definição do banco de dados, com isso teremos o mesmo texto sendo exibido em qualquer tela do sistema onde aquele campo for utilizado. De forma análoga podemos atribuir descrições para os campos das tabelas e exibir essas informações como hint nos componentes.
A seguir temos detalhados alguns detalhes sobre como o uso de dicionários pode facilitar o desenvolvimento e manutenção de sistemas em Delphi.
Para o banco de dados:
· Garantia de que a estrutura esteja condizente com a realidade: o dicionário, neste caso, será um espelho de como o banco de dados deverá ficar;
· Arquivo de "script" fica menor: como não teremos mais arquivos de scripts, o arquivo de dicionário os substituirá. Esse arquivo, a longo prazo, será proporcionalmente menor que os scripts devido à não redundância das informações. Além disso, armazenar a estrutura de uma tabela é mais simples que armazenar seus comandos SQL equivalentes;
· Possibilidade de rollback: como o banco será estruturado de acordo com o dicionário, e este contém apenas a estrutura e não comandos SQL, fica fácil pegar a estrutura do dicionário e aplicar no banco, então para efetuar o rollback, basta utilizar a versão anterior do dicionário.
Para o sistema:
· Podemos utilizar o dicionário para definir se um campo é obrigatório, não tendo mais necessidade de deixar isso fixo no código. Em caso de um campo se tornar obrigatório ou não no dicionário, isso irá refletir no sistema sem codificação e na maioria das implementações sem a necessidade de rodar uma nova versão, tendo que apenas reenviar o dicionário para o cliente;
· Captions e Hints refletem no sistema sem a necessidade de códigos engessados. Assim como nos campos obrigatórios, em caso alterações não necessitamos de uma nova versão;
· Podemos criar domínios e validações exclusivas para um determinado grupo de colunas e empregá-las apenas informando no dicionário. Um exemplo para isso seria a máscara de um telefone;
· Podemos definir a ordem de apresentação das colunas pelo dicionário, retirando essa tarefa do programador e deixando centralizado no dicionário, isso torna a alteração muito mais fácil;
· O sistema conhece completamente a estrutura do banco de dados.
Criando o Dicionário
A partir de agora vamos criar nosso dicionário de dados e utilizá-lo em uma aplicação. Para isso, precisamos primeiramente definir o que desejamos armazenar no dicionário, que serão basicamente as informações que definem as tabelas, colunas e índices do banco de dados. Nas Tabelas 1 a 3 vemos quais dados serão salvos no arquivo e seu significado para a aplicação.
|
Dados da Tabela |
|
|
Dado |
Descrição |
|
Nome |
Representa o nome da tabela |
|
Descricao |
Descrição da tabela |
Tabela 1. Dados da tabela
|
Dados das colunas |
|
|
Dado |
Descrição |
|
Ordem |
Nos informa em qual ordem o campo deve ser apresentado no grid |
|
Nome |
Representa o nome da coluna |
|
Descricao |
Descrição da coluna |
|
Caption |
Texto que deve ser apresentado para essa coluna |
|
Hint |
Hint que deve se apresentado para essa coluna |
|
Tipo |
Tipo de dados no banco de dados |
|
Tamanho |
Tamanho da coluna |
|
Decimal |
Caso seja valor numérico, utilizar para casas decimais |
|
Obrigatorio |
Define se a coluna é de preenchimento obrigatório |
|
AutoIncremetar |
Define se a coluna é auto incremental |
|
Único |
Define se os valores para essa coluna são únicos |
|
Valor_Defaut |
Valor padrão para a coluna |
|
Visivel |
Define se esse campo vai ser visível no sistema |
Tabela 2. ...
