Atenção: esse artigo tem um vídeo complementar. Clique e assista!

A padronização da nomenclatura de estrutura de dados nada mais é do que criar os objetos de banco de dados que possuem as mesmas funções de uma maneira uniforme, onde só de olhar seu nome seja possível identificar o que é, a quem pertence e o que ele faz.

Apesar de parecer algo óbvio, a padronização das estruturas de bases de dados não é uma prática entre a maioria das empresas que tem desenvolvimento próprio ou possuem sistemas feitos por encomenda.

Hoje não é difícil encontrar bases de dados geradas a partir de modelos de classes, onde os atributos descritos em cada classe se transformam em colunas de uma tabela sem nenhum tratamento, e por este motivo, algumas colunas não possuem significado. Por exemplo, observe a coluna “Nome” da Figura 1, este termo não é auto explicativo, ou seja, ele deixa dúvidas. Não é possível afirmar se o “Nome” é o nome do cliente, do atendente ou qualquer outra coisa.

Figura 1. Tabela gerada a partir de um Modelo de Classe.

Existem vários outros exemplos que não necessariamente são derivados de modelos de classes. Há casos de tabelas sem significado aparente, com nomes indecifráveis como "XX", "tblTeste", "tbl_001", "Plan1" e etc, e suas colunas seguem com os mesmos problemas de entendimento e na grande maioria, não tem seu comentário preenchido, dificultando ainda mais o entendimento.

É claro que a padronização não é essencial para que uma base de dados funcione adequadamente e nem tem obrigação de tornar os dados confiáveis, mas mostra o nível de maturidade da empresa e dos profissionais responsáveis pela administração ou criação das estruturas de dados.

Então, da mesma forma que usamos endentação para melhorar a visualização e facilitar o entendimento de nossos códigos SQL, é possível adotar padrões simples que vão deixar sua base de dados organizada e de fácil entendimento.

A intenção aqui não é criar um manual de padrões e normas para construção de bases de dados, nosso foco é melhorar a qualidade das estruturas de dados de uma maneira simples e eficiente.

Certamente se a empresa que você trabalha tem um administrador de dados, muitos desses conceitos já são utilizados, mas de qualquer maneira você vai descobrir o porquê foram aplicados.

É possível criar inúmeros modelos de padronização, sendo assim, não existe certo ou errado, mas tome cuidado com os exageros ou falta de critérios, não deixe nenhum item de fora para não gerar duvidas no momento da aplicação.

Regras básicas

Antes de tudo, você deve sempre respeitar as características e limitações do seu SGBD (ler Nota DevMan 1), por exemplo: o Oracle não aceita mais do que 30 caracteres para nomear um objeto, mas temos que concordar que ultrapassar essa limitação, mesmo para os SGBDs que permitem 256 caracteres, seria um exagero.

Veja abaixo algumas outras limitações encontradas nos principais SGBDs para nomes de tabelas, colunas index e outros:

1. Não usar espaço em branco;

2. Não usar hífen, acentos e caracteres especiais;

3. Não usar palavras reservadas como: INSERT, DELETE, SELECT e etc.;

4. Não usar mais que 30(trinta) caracteres;

Aliadas a essas limitações, seguem abaixo também algumas sugestões:

5. Não usar verbos;

6. Escrever em maiúsculo ou minúsculo;

7. Não utilizar palavras no plural;

8. Não usar preposições;

9. Não usar números;

10. Não usar nomes próprios;

11. Separe os nomes com underline;

12. Crie nomes sucintos e objetivos;

13. O nome não pode ter várias interpretações;

14. Todos os objetos devem possuir um prefixo, com exceção das tabelas operacionais (ler Nota DevMan 2).