Artigos Banco de Dados As vantagens do uso de padronização em objetos no banco de dados

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.

Modelo de dados de vendas sem padronização dos nomes de tabelas e colunas
Figura 1. Modelo de dados de vendas sem padronização dos nomes de tabelas e colunas

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:

Um script que cria tabelas sem utilizar padrões
Figura 2. Um script que cria tabelas sem utilizar padrões

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.

Inserindo 2 linhas em uma tabela com o mesmo valor da PK (chave primária)
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.

Modelo de dados de vendas com padronização dos nomes de tabelas e colunas
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:

Um script que cria tabelas utilizando padrões nos nomes de : tabelas, colunas e constraints
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.

Inserindo 2 linhas em uma tabela com o mesmo valor da PK (chave primária)
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
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.