Fatec Disciplina: LES - Laboratrio de Engenharia de Software - Prof.

Fernando Martins
Turmas: Noturno:

Tera-feira das 19:00 h as 22:30 h na sala de aula

Matutino: Quinta-feira das 07:40 h as 11:10 h no laboratrio.

Padronizao de nomenclatura de banco de dados

http://reginaldojr.wordpress.com/2008/06/20/padronizacao-de-nomeclatura-de-banco-de-dados/
20.06.2008
Reginaldo Jr.Projeto de software, Todosbanco da dados, nomeclatura, padronizao11 Comentrios
Eis uma coisa complicada. Cada programador, analista ou DBA tem uma forma de entender e montar uma
estrutura de banco de dados.
Lembro-me do tempo do CLIPPER onde os arquivos DBFs e NTXs eram bem limitados. Tinha um esquema
comumente chamado de 8.3 para nome de tabelas e quantidade limitada de caracteres para nome de campos.
Tinhamos que fazer verdadeiros milagres no momento de dar nome as campos das tabelas. Haja abreviaes.
Era preciso definir padres para as abreviaes, bem documentados, para que outro programador pudesse
entender, ou mesmo, o prprio desenvolvedor entendesse o que havia feito na hora de dar manuteno no
sistema.
Com o avano tecnolgico, muita coisa mudou nessa rea. Por exemplo, a evoluo dos sistemas operacionais
nos permite identificar com mais clareza os arquivos. De igual forma, os bancos de dados relacionais. Houve
um aumento no tamanho permitido para nome de tabelas, campos, chaves, etc.
Porm, com todo esse avano, vejo que muita gente quer preservar algumas caractersticas legadas para dar
nome s entidades relacionais do banco de dados. Por exemplo: um campo da tabela que servir pra guardar
endereo, h quem utilize END para nome do campo; um campo utilizado pra guardar a razo social, ha quem
utilize RAZ_SOC para nomear o campo. Eu pergunto: PRA QUE TANTA ABREVIAO DE NOMES,
HOJE EM DIA? Se o banco permite, porque no utilizar os nomes sem abreviaes desnecessrias?! As
justificativas apresentadas so as mais variadas. Mas no ouvi nenhuma que seja realmente convicente.
Inclusive, se for uma prtica do leitor usar essas abreviaturas nos bancos de dados atuais, peo que registre um
comentrio explicando o seu motivo pra abreviar.
Mas no s essa questo. Por exemplo, alguns analistas tem o costume de identificar os tipos de entidade no
nome da entidade. Por exemplo: A tabela de usurios ser nomeada assim: TB_USUARIO. Uma vez eu vi uma
situao que achei um excesso. Uma tabela com o seguinte nome de campo: TB_USUARIO_LOGIN, ou seja, o
nome da tabela compondo o nome do campo. Essa prtica pouco indicada pra quem trabalha com orientao a
objeto. Quem trabalha mapeamento O/R (como no Hibernate, por exemplo) ter um trabalho dobrado pra
reduzir estes nomes; para adequar os nomes das tabelas definio das classes persistentes.
Mas a realidade essa: cada um com sua forma de pensar. Nas prximas linhas vou definir a minha. Como eu
utilizo geradores de cdigo a partir de definies de banco, importante adotar um comportamento padro.
Vamos l.

Definies Gerais
1.
2.
3.
4.
5.

Evitar abreviaes. O nome completo deve ser preferido.

S utilizar letras maisculas.
O nome das entidades de banco deve ser no singular.
Procurar utilizar nomes que identifiquem sua utilidade e aplicao.
Para nomes compostos, separar com underline, por exemplo: RAZAO_SOCIAL.

6. Evitar usar o nome da entidade em seus componentes internos, por exemplo: Se o nome da tabela for
PACIENTE, o campo para preenchimento com o nome do paciente ser NOME e no
NOME_PACIENTE.

Tabelas
Para objetos relacionados com tabelas (chave primaria, chave estrangeira, campos, indices, etc.) vamos adotar o
seguinte comportamento:
Chave Primaria
1. No usar chave primria composta.
2. Deve ser sempre o primeiro campo na tabela e ser formado por ID_NOME_DA_TABELA. Para
tabela PACIENTE, por exemplo, o campo de chave primria ser ID_PACIENTE.
3. O tipo do campo deve ser do tipo numrico mais abrangente possvel ( numeric[18,0], bigint ), autoincremental, com sequence ou generator, se necessrio. No use triggers para auto-incrementar o
campo.
ndices
1. Deve ser criado sempre; de acordo com as necessidades de ajuste do banco. Normalmente os campos
utilizados para ordenao e filtro nas querys precisam de ndices.
2. Para os campos que poderiam ter sido escolhidos para chave primria composta, construir o ndice com
a combinao dos campos utilizando ndices marcados como nicos (unique).
3. Seguindo uma sugesto de um de nossos leitores (Moriarty), deve ser formado por
IX_TABELA_CAMPO. Por exemplo: a tabela PACIENTE ter dois ndices, nome e registro:
IX_PACIENTE_NOME e IX_PACIENTE_REGISTRO. Essa forma substituiu a anterior onde no lugar
do nome do campo a utilizao era de um nmero sequencial, por exemplo, IX_PACIENTE1,
IX_PACIENTE2.
Chaves estrangeiras
1. Na tabela, o nome do campo deve ser igual ao campo chave primria da tabela a que corresponde.
2. Identificado assim: FK_NOME_DA_TABELA_NOME_DA_TABELA_ESTRANGEIRA. Por
exemplo: a tabela PACIENTE possui uma chave estrangeira para tabela SEXO cuja chave primria
ID_SEXO. O nome do campo na tabela PACIENTE deve ser tambm ID_SEXO e o nome da chave
estrangerira ser FK_PACIENTE_SEXO.
3. Se o nome ficar muito grande e o banco no aceitar criar, nesse caso, permitida uma abreviao.
Restries (constraint)
1. A nica restrio obrigatria a NOT-NULL. Obviamente as restries de relacionamento e ndices so
indispensveis. Outras como, por exemplo, as restries para valores vlidos nos campos, so opcionais.
Tipos
1. Respeite o tipo de dado para o campo. Campo data para guardar datas, numricos para guardar nmeros,
etc.
2. Alguns bancos disponibilizam tipos comuns com quantidade de bytes reduzidas. Por exemplo: para
campo numrico existe: int, smallint, tynint, etc. Procure evitar as variaes. Prefira os tipos que so
comuns a todos os tipos de bancos. Use os tipos abaixo. Eles costumam ter tamanho bem definido e
nome de tipos comuns a todos os bancos.

Numricos: int ou integer

Data: DateTime ou TIMESTAMP
String: varchar

Boolean: smallint ou bit

Campos bynrios ou longos: BLOB

SEQUENCE ou GENERATOR
1. Deve ser criada da seguinte forma: GEN_NOME_DA_TABELA_ID. Para a tabela PACIENTE crie um
sequence ou generator GEN_PACIENTE_ID.
2. Se o nome ficar muito grande e o banco no aceitar criar, nesse caso, permitida alguma abreviao.

Vises
1. O nome da view deve ser V$NOME_VIEW ou VNOME_VIEW. Ex: V$PACIENTE_INTERNADO ou
VPACIENTE_INTERNADO

Procedures, Functions, Triggers

Eu evito terminantemente utilizar objetos que possam exigir reescrita caso seja necessrio mudar de banco de
dados, exceto as views, claro. Inclusive eu escrevi um post sobre Independncia de Banco de Dados. Leia
mais

Nas aplicaes
1. Na criao de junes utilizarem explicitamente somente a combinao chave primaria/estrangeira
definida no projeto fsico do banco.
2. As selees de dados devem sempre utilizar um campo que possua ndice. O banco deve ser planejado
para realizar pesquisas utilizando os ndices.
3. Nas pesquisas com LIKE, o % deve ser usado sempre no final da seleo evitando seu uso no incio da
string. Isso melhora a performance da pesquisa.
4. Quando abrir uma transao deve-se testar antes todas as possibilidades de a transao poder ser
completada, ou seja, as validaes de dados, testes de integridade referencial, testes de violaes de
chaves, etc. devem ser feitas antes da abertura da transao. O rollback de uma transao deve ser
preferencialmente utilizado apenas para erros internos de banco e no por violao de alguma regra de
negcio.
5. Evitar select * from tabela. Devem-se discriminar exatamente os campos de retorno da seleo. Alm
disso, as selees devem ter algum objetivo, ou seja, uma condio deve ser informada especialmente
em tabelas com grande nmero de linhas. Evitar deixar a cargo da aplicao os filtros e as selees de
dados que poderiam ser realizadas diretamente pelo banco atravs de uma query.
6. Mesmo que restries ou constraints estejam definidas no banco a aplicao deve tambm realizar essas
verificaes.
isso. Espero ter ajudado. Quem tiver alguma maneira diferente de entender ou enxergar este assunto, por
favor, no deixe de registrar um comentrio ou me enviar por email. Desde j obrigado.
Blz!
About these ads

Gostar disso:
Curtir
Seja o primeiro a curtir disso.

11 Comentrios (+add yours?)

1.

George Limeira
mar 30, 2010 @ 15:29:22

Bom, costumo colocar os nomes de tabelas todos comeando com TB_ + .

De cada Tabela, costumo estabelecer sempre um codnome com 4 letras. Ex.: TB_PEDIDO (PEDI);
TB_NT_FISCAL_ELE (NOFE).
Quando as 4 letras coincidentemente j existirem para uma outra tabela, Costumo obter a prxima letra.
Ex.: Se NOFE j existisse, eu geraria NTFE. Muito bem, mas para que eu irei querer este cognome
? Simplesmente para se tornar o prefixo de cada coluna da Tabela, exceto as FKs. Ex.:
NOFE_ID_NT_FISCAL_ELE; NOFE_NR_NT_FISCAL_ELE. Observeem que depois do Prefixo
NOFE_ colooco sempre um classificador da Coluna (Ex.: ID_ = Identificador da PK ; NM_ =
Nome ; DT_ = Data ; NR_ = Nmero ; CD_ = Cdigo ; ST_ = Situao; PC_ = Percentual;
VL_ = Valor; TP_ = Tipo; DS_ = Descrio; IN_ = Indicador S/N (Flag S/N); HR_ =
Hora; QT_ = Quantidade ; SG_ = Sigla; IM_ = Imagem (Foto em .JPG, por exemplo) ). Estes
classificadores padronizados permitem sempre uma qualificao fcil do que est essencialmente
guardado na coluna. Todo e qualquer coluna tero um deles. Outra coisa: O campo que for uma FK ter
o mesmo nome da PK, desta forma, por exemplo, em uma tabela dos itens de notas fiscais
(TB_NT_FISCAL_ELE_ITEM), seus campos comecaro com NFEI_ e as FK para a tabela
TB_NT_FISCAL_ELE ter o mesmo nome dado na origem, ou seja,
NOFE_ID_NT_FISCAL_ELE. Desta forma, eu sempre saberei onde nasceu o dado e, sendo assim
fica fcil, a qualquer momento, eu me sentir super seguro em relacionar qualquer tabela que tenha a
coluna NOFE_ID_NT_FISCAL_ELE com a Tabela TB_NT_FISCAL_ELE, sem sombra de
qualquer dvidas que dar certo. Observem tambm uma outra coisa: Todo e qualquer Coluna PK da
tabela, eu utilizo a Nomeclatura + ID_ + . Exemplo: Tabela TB_NT_FISCAL_ELE ter a sua
coluna PK sendo NOFE_ID_NT_FISCAL_ELE. Observem tambm que com esta regrinha eu sempre
saberei facilmente saber o nome da PK de qualquer tabela apenas sabendo o nome dela. Espero ter
contribudo. Um grande abrao a todos ! George Limeira
Resposta

2.

Moriarty
jul 20, 2010 @ 10:19:18

Bom dia,
Li seu artigo e no achei correto algumas coisas que voc colocou.
- ndice sequencial? E se eu quiser utilizar um determinado ndice, como saberei qual ele? Utilizo
sempre o ndice com o nome da tabela e o nome do campo. EX: IDX_PACIENTE_NOME
- No utilizar constraint? Como??? Voc pe no sistema uma responsabilidade que do banco.
Sinceramente no concordo.
- Usar chave estrangeira com outro nome que no seja o prprio nome do campo. Tambm no
concordo. Se a chave primria ID_PACIENTE ento ela tambm deve ser ID_PACIENTE em outra
tabela. Isso ajuda na hora de fazer um NATURAL JOIN.
- Utilizar NOME, ao invs de NOME_PACIENTE. Tambm no utilizo assim, principalmente quando
desejo realizar NATURAL JOIN (mesmo motivo do item anterior). Se duas tabelas relacionadas
tiverem o campo NOME, eu no conseguirei utilizar o NATURAL JOIN.
No geral, parabns pela iniciativa.

Abs
Resposta

3.

Marcio
nov 02, 2010 @ 08:12:29

E quanto a padronizar nomes de campos, vcs costumam utilizar?

Exemplo:
ds_nome (indica que a informao contida um char);
nr_qtde (indica ser um numrico);
vcs utilizam alguma padronizao neste sentido?
Resposta

4.

Almir Farias Rivas Junior

abr 26, 2011 @ 15:16:00

Posso publicar seu post no meu blog?

Resposta

Reginaldo Jr.

abr 29, 2011 @ 10:22:03

Ol, Almir. Claro que sim. Solicito apenas que preserve a referncia.
Resposta

5.

Daniel Moreira
jun 26, 2011 @ 13:13:16

Ol, gostei do seu post e sigo no mesmo caminho, e creio ir um pouco mais alm em nvel de
organizao. Aps a nomeclatura humana, ainda organizo todo os campos em ordem alfabtica:
Primeiro ID, depois FKs e em seguida todos os campos com seus nomes reais e humanamente
intendveis alfabeticamente. Hoje, h uma tendncia (que eu acho bem interessante) de tratar o banco
de dados apenas com um repositrio de dados. A importncia dos dados devem estar na aplicao que
os gerencia e no no banco. UM abrao.
Resposta

reginaldojr
jun 27, 2011 @ 11:04:36

ol, Daniel

Que bom que gostou do nosso trabalho. Realmente o uso do banco apenas como repositrio de
dados tem sido muito com. Nesse caso interessante utilizar um framework de persistncia. Eu
costumo usar o NHibernate. Conhece alguma coisa sobre isso?
Resposta

dmmoreira
jun 27, 2011 @ 12:45:53

Sim, uso h bastante tempo o NHibernate, h alguns anos adotamos esta topologia apra a
arquitetura das aplicaes que desenvolvemos onde trabalho: Asp.NET ou MVC
WinfForm ou WPF Oracle NHibernate , usando DDD como arquitetura bsica. um
abrao

6.

danilomoraes
ago 19, 2011 @ 01:11:43

Gostei do artigo, mas utilizo de maneira diferente em alguns aspectos:

Nomes de tabelas e colunas, sempre em minsculo. Os nomes compostos sempre separados por espaos:
data_cadastro, endereco_residencial
Nomes de tabelas de relacionamento, sempre coloco: tabela1-tabela2
Todos os relacionamentos eu indico com trao. Chave primria, sempre chamo de id e evito usar chave
composta. Fk, tambm uso o trao:
id
id-produto referencia o campo id da tabela produto
id-perfil referencia o campo id da tabela perfil
Underline uso apenas para juntar nomes compostos, trao para referenciar uma ligao:
perfil_ativo-preco_avaliado tabela de relacionamento entre a tabela perfil_ativo e a tabela
preco_avaliado.
At
Resposta

7.

diegorafaelss
abr 11, 2012 @ 15:57:29

Gostei do post!
Resposta

reginaldojr
abr 11, 2012 @ 18:28:32

Que bom que gostou. Quando puder, d uma olhadinha nos outros.

Resposta

Deixe uma resposta

Escreva o seu comentrio aqui...

Preencha os seus dados abaixo ou clique em um cone para log in:

(obrigatrio)(Seu endereo nunca ser divulgado)(obrigatrio)( Sair / Mudar )( Sair / Mudar )( Sair / Mudar )
Google Maps para ASP.NETVisual Studio + NHibernate: Construindo aplicaes em camadas
Posts Recentes

Nosso Agradecimento: 100.000 visitantes

Autenticao de Usurios em Sistemas Web .NET/WebForms
Leitor de Feeds RSS em C#
Busca Incremental em ASP.NET com Javascript
Incremente seu site
Definindo a Aparncia do Site
Planeje seu site
Gravar Arquivos em Banco de Dados
Clculo de Distncia e Tempo de Viagem entre Cidades Brasileiras
Google Maps com Javascript

Pesquisar..

Comentrios
Reginaldo Jr. em Clculo de Distncia e Tempo d
Paulo Rogrio em Clculo de Distncia e Tempo d
reginaldojr em Independncia de Banco de
diegorafaelss em Independncia de Banco de
reginaldojr em Independncia de Banco de
Categorias
Selecionar categoria

Construa seu site

RS Consultoria & Sistemas

RSClass

Meu site pessoal

Reginaldo Jr. Website

Arquivos
Selecionar o ms

Desde (04/11/07)

106,700 visitas

Blog no WordPress.com.