Inicio - SETI
- Governança-TIC
- 01. Estrutura do DTIC e Comitês
- 02. Estratégia de TIC
-
02. Plano Capacitação TIC
-
02. Plano Continuidade SE TIC
-
02. Plano Contratações TIC
- 02. Plano Diretor TIC
-
02. Plano Riscos TIC
-
02. Plano Transformação Digital
- 03. iGovTIC-JUD
- 03. Indicadores TIC
- 03. Pesquisa Satisfação TIC
-
04. Processos de TIC
- 05. Segurança de TIC
- 06. Portfólio de TIC
- Atendimento a Usuários
-
BI e Relatórios TIC
- Modelos e sobre TI
- Normativos TIC
-
Rede sem fio (Wi-Fi)
- Videoconferência
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.
sintaxe: MAP_Tabela
sintaxe: TMP_TABELA
ex: TMP_RELATORIO_PROCESSO
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.
sintaxe: IDX_Tabela_coluna
onde, Tabela é o nome da tabela e Coluna é o nome da coluna principal do índice.
Sintaxe: PK_Tabela
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
Sintaxe: CK_Tabela_coluna
Sintaxe: UK_Tabela_coluna
Sintaxe: VW_NomeDescritivo
Sintaxe: TRG_Tabela_operacao_L
Onde: operacao – delete, insert, update
L – B (Before), A (After)
Ex: TRG_Processo_delete_B
TRG_Processo_insert_A
Sintaxe: SP_atualizarFuncionario, SP_converterCarro, etc
Sintaxe: SQ_consultarProcesso, SQ_consultarApreensao, etc
Obs: Caso o SGBD permita, é conveniente agrupar as procedures em pacotes.
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.