As vantagens do uso de padronização em objetos no banco de dados
Olá amigo(a),
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.
Figura 1. Modelo de dados de vendas sem padronização dos nomes de tabelas e colunas.
Análise do Problema – Parte 1
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:
Figura 2. Um script que cria tabelas sem utilizar padrões.
Análise do Problema – Parte 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.
Figura 3. Inserindo 2 linhas em uma tabela com o mesmo valor da PK (chave primária)
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.
Figura 4. Modelo de dados de vendas com padronização dos nomes de tabelas e colunas.
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:
Figura 5. Um script que cria tabelas utilizando padrões nos nomes de : tabelas, colunas e constraints.
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.
Figura 6. Inserindo 2 linhas em uma tabela com o mesmo valor da PK (chave primária)
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 |
...
31/05/2007 21:03:00
2007
2007
13
0
