A padronização de objetos em banco de dados é utilizada em larga escala em projetos onde são utilizados modelos de qualidade como: CMMI, PMI, ISO9005, entre outros. Muitas das empresas que não possuem esse tipo de metodologia implementada, constantemente buscam novas práticas de gerenciamento para diminuir seus custos diretos de desenvolvimento e manutenção de software.
Atualmente, o custo com as manutenções feitas nos aplicativos customizáveis, isto é, aqueles em que os desenvolvedores possuem o código fonte em mãos, corresponde a um dos grandes vilões no orçamento da área de desenvolvimento de software, deixando muitos gerentes de "cabelo em pé". O problema se agrava ainda mais quando estas manutenções são destinadas aos retrabalhos, e não para o desenvolvimento de novas funcionalidades.
A idéia do artigo dessa semana é demonstrar através de exemplos práticos como diminuir o custo na fase de desenvolvimento e manutenção do software por meio da definição de padrões no modelo de dados físico. O objetivo a ser alcançado é facilitar o entendimento dos desenvolvedores para que na fase de programação; a identificação das tabelas do sistema, seus atributos (colunas), os relacionamentos existentes e as constraints (restrições) sejam claras e precisas, facilitando o manuseio aos dados e consequentemente diminuindo o tempo de análise e programação.
O Problema
Como início do trabalho, o exemplo abaixo trata de um modelo de dados sem padronização, que exige análise por parte do desenvolvedor para realizar a programação da aplicação.
Análise do Problema
Analisando cuidadosamente os nomes das tabelas e suas respectivas colunas, percebe-se claramente a dificuldade que o desenvolvedor irá ter para realizar o desenvolvimento da aplicação, ou até mesmo necessite fazer uma manutenção, como a formatação (máscara) de uma coluna na tela. Para iniciar o trabalho, o desenvolvedor terá que verificar cuidadosamente o dicionário de dados para identificar qual é o significado de cada coluna, bem como o nome das tabelas.
Indo um pouco mais além, o script desse modelo de dados é executado no ambiente de banco de dados, conforme mostra a Figura 2:
O script gerado acima contém um dos principais problemas encontrados atualmente na modelagem de dados: “A ausência de identificar as constraints (Primary Key, Foreign Key,
NOT NULL entre outras)”
Sem as restrições (constraints) nomeadas de forma correta, a dificuldade para realizar um suporte em tempo hábil será muito grande, pois a mensagem de erro exibida não será significativa. Isso é claramente visível no exemplo da figura 3, que irá inserir 2 linhas na tabela, sendo que a 2ª linha tem o mesmo código da chave primária da 1ª. , ocorrendo em uma mensagem de erro com o nome SYS_COO112132, ou seja, indecifrável.
O simples exemplo citado acima demonstra que quando mais tabelas que não estejam
utilizando um padrão de nomenclatura, a complexidade de se realizar manutenção aumenta consideravelmente, afetando diretamente o custo de manutenção/desenvolvimento do software.
A solução
Modelo de dados utilizando padrões
Agora utilizaremos o mesmo exemplo da Figura 1, porém utilizando uma padronização simples.
Analisando cuidadosamente os nomes das tabelas e suas respectivas colunas, percebe-se que o desenvolvedor encontra um nome significativo para as colunas e tabelas, facilitando seu trabalho, para realizar a formatação (máscara) das colunas na tela, bem como realizar a programação para a entrada de dados.
Realizando a implementação física desse modelo no ambiente de banco de dados, tem-se o seguinte script executado na Figura 5:
Apesar do script gerado conter mais linhas do que o exemplo da figura 2, ocorreu uma
definição adequada de todos os nomes de tabelas, colunas e restrições existentes na aplicação, facilitando a identificação interna dos objetos criados no banco de dados.
Para realizar um teste prático, foi utilizado o mesmo comando insert da Figura 3.
A mensagem de erro exibida na figura 6 (que é o mesmo erro da figura 3) está muito mais
clara: PK_DEPTO, ou seja, violação da PK (Primary Key). Para realizar o suporte, o desenvolvedor conseguirá identificar facilmente o problema somente pela mensagem de erro exibida e resolve-lo em um menor tempo do que o exemplo do modelo com falta de padronização.
Considerações finais
A tabela 1 (abaixo) contém algumas sugestões para criar nomes de colunas e restrições no banco de dados na fase de implementação física no banco de dados.
Sugestão de padrões para criar nomes de colunas no modelo físico
| Identificação | Descrição do atributo | Tipo de dado utilizado |
|---|---|---|
| CD | Nome de coluna que irá armazenar valores numéricos inteiros, utilizado em atributos falsos. | Numérico |
| DT | Nome de coluna que irá armazenar valores do tipo data | Data |
| DS | Nome de coluna que irá armazenar valores “string”, ou seja, caracteres que são descritivos e com grande capacidade de armazenamento. | String (caracteres) |
| NM | Nome de coluna que irá armazenar valores “string”, ou seja, caracteres. | String (caracteres) |
| NR | Nome de coluna que irá armazenar valores numéricos inteiros, para conteúdos significativos. | Numérico |
| ST | Nome de coluna que irá armazenar valores do tipo caracteres com conteúdo pré-estabelecido. Ex. Coluna ST_Cliente pode ter seu conteúdo como sendo “A” ou “I” e nenhum outro valor a não ser esses estipulados | String (caracteres) |
| VL | Nome de coluna que irá armazenar valores numéricos, ou seja, números que podem possuir casas decimais | Numérico |
Sugestão de padrões para criar restrições no modelo físico
| Identificação | Descrição do atributo |
|---|---|
| PK_ | Nome da chave primária de uma determina tabela |
| FK_ | Nome da chave estrangeira associada a uma determinada tabela |
| IDX_ | Nome de índices associados a uma determinada tabela |
| NN_ | Nome de uma restrição do tipo Not Null, ou seja, coluna obrigatória |
| CK_ | Nome de uma restrição do tipo check, ou seja, valores pré-definidos. Exemplo: coluna sexo, valores possíveis ou ou de armazenamento |
Conclusão
Para que a sua aplicação possa fornecer mensagens claras em um momento de anormalidade, utilize padrões para diminuir o tempo total de downtime da aplicação.
Técnicas para definições de objetos no banco de dados garantem o bom atendimento no suporte do software, bem como transmite segurança a todos os envolvidos para manter a aplicação com disponibilidade.
No próximo artigo iremos bater um bate-papo com um dos OraSauros mais famosos que atuam no mercado de trabalho, participando de diversas comunidades on-line. Ele trará dicas de como ingressar de forma correta no aquecido mercado das ferramentas Oracle.
Agradeceria de coração sugestões e comentários desse artigo para que seja possível replicar mais conhecimentos a todos nós.
