A abordagem adotada neste padrão tem grande influência do banco de dados Intersystems Cachê 5.0.18 Muitas convenções de nomenclatura tem origem em limitações e/ou particularidades deste banco de dados. Alguns padrões foram adotados para facilitar o mapeamento semi-automático que pode ser facilitado por meio da ferramenta Enterprise Architect.

Características gerais

  • Todos os nomes de objetos devem estar no singular, respeitar as palavras reservadas e o limite máximo do SGBD/ERwin. Abreviar palavras somente quando ultrapassar esse limite. Em geral os nomes seguem o padrão de nomenclatura do Java em português.
  • Não devem ser utilizados prefixos identificando o sistema ou cliente proprietário do objeto, essa diferenciação deve ficar a cargo da utilização de esquemas de usuário.
  • Não devem ser utilizados identificadores não mnemônicos, tais como: números, intervalos de letras, etc; em razão de dificultar a memorização dos nomes dos objetos. Ex: Processo1, ProcessoA, Processo_Criminal2, etc..

Siglas

Seguem o padrão da nomenclatura do Java normalmente.

Tabelas em Geral

Seguem o padrão de nomenclatura do Java para as classes, ou seja: inicial de cada palavra em maiúsculo.

Tabelas Mapeadas

As globais do mumps mapeadas para tabelas através do Caché devem ser identificadas com o prefixo “MAP_”. Essas tabelas podem ter muitas limitações quanto à criação de índices, tipos de dados, e aceitação de instruções DDL, entre outras, por isso essa diferenciação é importante.
sintaxe: MAP_Tabela

Tabelas Temporárias

Seguir as mesmas orientações de tabela de dados, acrescentando o prefixo de “TMP”. Preferencialmente criar tabelas temporárias somente em casos extremos, é necessária a criação de identificadores de sessão para a tabela temporária (visando evitar mistura de dados de usuários ) quando o SGBD por si só já não o fornecer.
sintaxe: TMP_TABELA
ex: TMP_RELATORIO_PROCESSO

Tabelas Associativas

As tabelas associativas criadas unicamente para viabilizar relacionamentos muitos_x_muitos (tabelas que não tem outras colunas além das chaves estrangeiras relacionadas) devem receber o nome das tabelas participantes da associação.
Sintaxe: Tabela1_Tabela2
Ex: Tabela associativa entre as tabelas Processo e Protocolo
Processo_Protocolo

Caso exista alguma outra informação na tabela associativa, isto é, ela também possui algum significado no contexto de negócio, o nome da tabela deverá ser significativo e de acordo com seu propósito. Ex: A associação entre Réu e Processo pode possuir algumas colunas a mais além das duas chaves, como o crime cometido pelo réu naquele processo. Nesse caso é mais conveniente nomear a tabela associativa de acordo com o negócio, nessa caso como PARTE, já que respeita as regras de negócio.

Colunas

Seguindo o mesmo padrão baseado na semântica, identificar a coluna da tabela de maneira clara e bastante descritiva. A inicial de cada palavra deve ser em maiúsculo com exceção da primeira.
  • Não deve ser usado “-” (underscore).
  • Não utilizar identificação do tipo no nome da coluna.
  • Nas colunas originadas no mapeamento a partir de uma classe diferente, acrescentar o nome da classe original como sufixo. Ex: Na tabela Pessoa o atributo "ctps" originado a partir da classe "Funcionario" será ctpsFuncionario

Identificador da Tabela

Para todas as tabelas não associativas, acrescentar uma coluna identificadora para a tabela cujo nome será “id” seguido do nome da tabela.

Índices

Seguir as mesmas orientações de tabela de dados, acrescentando o prefixo “IDX” e um sufixo descrevendo a tabela e os atributos (coluna) do índice.
sintaxe: IDX_Tabela_coluna
onde, Tabela é o nome da tabela e Coluna é o nome da coluna principal do índice.

Constraint

Devem ser definidas no Hibernate e no SGBD.

Primary Key

Seguir as mesmas orientações quanto ao uso de semântica. Deve ser prefixado por “PK” acrescido do nome da tabela.
Sintaxe: PK_Tabela

Foreign Key

Seguir as mesmas orientações quanto ao uso de semântica nos nomes. Deve ser prefixado por “FK”, acrescido do nome da tabela de origem e da tabela destino.
Sintaxe: FK_TabelaOrigem_TabelaDestino

Obs: Caso exista mais de um relacionamento entre duas tabelas, utilize o nome do relacionamento, ou o papel que originou o relacionamento para diferenciar as FK's: Ex: Entre a tabela Pessoa e Pedido existem duas FK's onde uma representa o papel “Vendedor” para Pessoa e outra o papel “Cliente” para Pessoa.
FK_vendedor_Pedido e FK_cliente_Pedido

Check Key

Seguir as mesmas orientações quanto ao uso de semântica. Deve ser prefixado por “CK” acrescido do nome da tabela.
Sintaxe: CK_Tabela_coluna

Unique Key

Seguir as mesmas orientações quanto ao uso de semântica. Deve ser prefixado “UK” acrescido do nome da tabela.
Sintaxe: UK_Tabela_coluna

Views

Seguir as mesmas orientações quanto ao uso de semântica. Deve ser prefixado “VW” acrescido de um nome significativo.
Sintaxe: VW_NomeDescritivo

Triggers

Seguir as mesmas orientações de tabela de dados. Acrescentar o prefixo “TRG” e um sufixo indicando a operação objeto da trigger e a tabela que dispara a trigger.
Sintaxe: TRG_Tabela_operacao_L
Onde: operacao – delete, insert, update
L – B (Before), A (After)
Ex: TRG_Processo_delete_B
TRG_Processo_insert_A

Stored Procedures e Stored Queries

Os procedimentos armazenados e eventualmente as consultas armazenadas deverão ser prefixados com SP ou SQ, conforme o caso. Além de seguir as demais regras de utilização de nomes significativos.
Sintaxe: SP_atualizarFuncionario, SP_converterCarro, etc
Sintaxe: SQ_consultarProcesso, SQ_consultarApreensao, etc
Obs: Caso o SGBD permita, é conveniente agrupar as procedures em pacotes.