PUCRS - Uso Restrito

typesese
M

PADRÕES DE
NOMENCLATURA PARA
OBJETOS DE BANCO DE
DADOS
Oracle

Resumo
Formalizar os padrões de nomenclatura dos objetos criados no banco de dados.

Camila Conti, Douglas Oliveira, Evandro Esteves, Leonardo Panatta, Loraine

Pivatto, Patrick Santos, Marcelo Yamaguti, Roberto Schroeder, Sandro Kowalczuk.
 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

Sumário

1. Nomenclatura de Sistemas (≈ Owner do BD).....................................................................................2

2. Nomenclatura dos objetos.................................................................................................................2
2.1. Tabela.........................................................................................................................................3
*Para a chave primária (Primary Keys – PKs) deve ser seguida a orientação:....................................4
2.2. Coluna.........................................................................................................................................6
2.3. Constraint...................................................................................................................................8
2.4. Trigger.........................................................................................................................................9
2.5. View..........................................................................................................................................10
2.6. Materialized View.....................................................................................................................11
2.7. Sequence...................................................................................................................................11
2.8. Índice........................................................................................................................................12
2.9. Function, Stored Procedure e Package.....................................................................................12
2.10. Conceitos e características de LOG e HISTÓRICO....................................................................13
3. Histórico de Revisões.......................................................................................................................14

Versão: 2.0.0 Página 1 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

Os padrões de nomenclatura para objetos criados de banco de dados (BD) detalhados nesse
documento são válidos para objetos de sistemas desenvolvidos e mantidos pela GTIT e sistemas
desenvolvidos em parceria com fornecedores, o que não inclui soluções de prateleira.

1. Nomenclatura de Sistemas (≈ Owner do BD)

Os sistemas em sua maioria estão associados a um Owner no BD, contudo pode acontecer de não ter
como no caso dos sistemas Corporativo e PGCURSO - Cadastro de Cursos PRPPG.
Todos os sistemas devem possuir uma sigla, composta por 2 ou 3 letras. A sigla será utilizada como
prefixo no nome dos objetos de banco de dados gerados para o sistema, assim facilitando a identificação e
evitando duplicidade.
Alguns exemplos:
Sigla Sistema
ATA Sistema de Atas
EX Extensão
FA Financeiro
GEN Genérico (Contêm tabelas, rotinas, funções, etc. genéricas à PUCRS)
GR Graduação
PG Pós-Graduação
SIU Sistema de Identificação Unificada

2. Nomenclatura dos objetos

Abaixo os objetos mantidos no BD serão detalhados com seus respectivos conceitos, em linhas
gerais, e o padrão de nomenclatura adotado pela GTIT o qual deve ser seguido. É responsabilidade das
equipes de desenvolvimento e DBAs garantir o uso correto desses.
Regras gerais ao criar objetos no BD:
 Possuir nomes sugestivos, facilitando a identificação do seu conteúdo e objetivo;
 Estar no singular;
 Sem acentuação;
 Sem preposição (tais como: do, de etc.);
 Sem caracteres especiais (tais como: @, #, $, %, &, etc.);
 No caso de nome compostos devem ser separados por sublinhado ( _ );
 Possuir no máximo 30 caracteres, abrevie se necessário.

Versão: 2.0.0 Página 2 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

2.1. Tabela

É uma estrutura matricial composta por linhas, também conhecida como tuplas, e colunas, onde
cada linha representa um objeto do negócio e cada coluna representa uma característica dele.
Ao criar novas tabelas, lembre-se de inclui comentários*, criar uma chave primária* e avaliar a
necessidade de criar colunas padrões para auxiliar na identificação do último usuário que atualizou o
registro:
 DT_ALTERACAO;
 NR_OPERADOR varchar2 (15) not null;
 CD_IP varchar2 (30) null.

Padrão de nomenclatura TABELAS

(Tipo de Tabela | Padrão de Nomenclatura)

Tabelas padrões / simples <SIGLA SISTEMA>_<NOME TABELA>

Exemplo: PG_CURSO

Tabelas resultantes do relacionamento <SIGLA SISTEMA>_<NOME TABELA 1> __<NOME TABELA 2>
entre outras duas tabelas: utilize dois
Exemplo: CP_ATIVIDADE__PROFESSOR
sublinhados (__) para separar as tabelas.

Tabelas temporárias <SIGLA SISTEMA>_<NOME TABELA> _TEMP

Tabelas de log: utilize a trigger que <SIGLA SISTEMA> _<NOME TABELA>_LOG

mantém o formato padrão. (Veja abaixo)
Exemplo: GR_CURRICULO_NIVEL_LOG

Legenda:
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME TABELA>, <NOME TABELA1> e <NOME TABELA2>: nome representativo.

Para tabelas de log utilize trigger que mantém o formato padrão facilitando o entendimento e
manutenção futura por toda a equipe de desenvolvimento. Veja o exemplo:
CREATE OR REPLACE TRIGGER trg_gr_curriculo_nivel_aiud
  AFTER INSERT OR UPDATE OR DELETE
  on gr_curriculo_nivel
  FOR EACH ROW
declare
  V_USU varchar2(10);
  V_IP  varchar2(15);
  E_USU exception;
begin

  V_USU:= pkg_contexto.p_get_contexto_var('contexto_usuario','sistseg_user');
  V_IP := pkg_contexto.p_get_contexto_var('contexto_usuario','ip');

Versão: 2.0.0 Página 3 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

  IF (trim(V_USU) IS NULL) OR (trim(V_IP) IS NULL) then

     raise E_USU;
  END IF;

  IF inserting THEN
     INSERT INTO GR_CURRICULO_NIVEL_LOG (
       CHAVE_PRIMARIA,COLUNA,
       tp_operacao, dt_operacao, cd_operador, tx_ip
       )
       VALUES (
       :new.CHAVE_PRIMARIA,:new.COLUNA,
      'I', sysdate, V_USU, V_IP
       );
  ELSIF updating THEN

    IF
      NVL(:NEW.COLUNA,'X') <> NVL(:OLD.COLUNA,'X')
        THEN
      INSERT INTO GR_CURRICULO_NIVEL_LOG (
       CHAVE_PRIMARIA,COLUNA,
       tp_operacao, dt_operacao, cd_operador, tx_ip
       )
       VALUES (
        nvl(:new.CHAVE_PRIMARIA,:old.CHAVE_PRIMARIA),
        decode (:new.COLUNA, :old.COLUNA, null, :new.COLUNA),
        'A', sysdate, V_USU, V_IP
       );
    END IF;
  ELSIF deleting THEN
      INSERT INTO GR_CURRICULO_NIVEL_LOG (
          CHAVE_PRIMARIA,
          COLUNA,
          tp_operacao, dt_operacao, cd_operador, tx_ip
          )
      VALUES (
         :old.CHAVE_PRIMARIA,
         :old.COLUNA,
         'E', sysdate, V_USU, V_IP
         );
  END IF;

  Exception
  when E_USU then
   RAISE_APPLICATION_ERROR(-20300, 'Usuário e/ou Ip não foi definido.');

end;
/

*Para a chave primária (Primary Keys – PKs) deve ser seguida a orientação:

Deverá ser criada uma coluna numérica especificamente para o uso da PK, sendo uma sequência.
Conforme as boas práticas descritas abaixo.
Algumas situações que podem ocorrer:

Versão: 2.0.0 Página 4 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

 Há algum campo único na tabela (CPF, COD_MATRICULA): neste caso, deverá ser criada uma coluna
numérica e sequencial especificamente para o uso da PK. O campo único deverá ser estabelecido
através de Unique Key.
 Deve ser criada uma nova tabela em um Owner cuja a tabela de relacionamento tenha uma PK que é
um código (CPF, MATRÍCULA): neste caso, deverá ser criada uma coluna numérica e sequencial
especificamente para o uso da PK. Se houver campo único (nova tabela) deverá ser estabelecido
através de Unique Key e o relacionamento feito por Foreign Key entre a PK da tabela antiga e a UK
da tabela nova.
#######################################################################################

Choosing a Primary Key for a Table

(PRIMARY KEY Constraint)
The primary key of a table uniquely identifies each row and ensures that no duplicate rows exist
(and typically, this is its only purpose). Therefore, a primary key value cannot be NULL.
A table can have at most one primary key, but that key can have multiple columns (that is, it can
be a composite key). To designate a primary key, use the PRIMARY KEY constraint.
Whenever practical, choose as the primary key a single column whose values are generated by a
sequence. For information about sequences, see Oracle Database SQL Language Reference.
The second-best choice for a primary key is a single column whose values are all of the
following:
 Unique
o Never changed
 Never NULL
 Short and numeric (and therefore easy to type)
Minimize your use of composite primary keys, whose values are long and cannot be generated
by a sequence.

See Also:
 Oracle Database Concepts for general information about primary key constraints
o Oracle Database SQL Language Reference for complete information about primary key
constraints, including restrictions

Fonte:
https://docs.oracle.com/cd/E11882_01/appdev.112/e41502/adfns_constraints.htm#ADFNS99957

*Os comentários devem ser incluídos a fim de facilitar a identificação do objetivo da tabela e de cada
coluna.
Por exemplo:
O campo DT_INCLUSAO com o comentário 'Data de inclusão do registro', não é necessário.
Já o comentário para o campo NR_CARGA_HORARIA_USADA = 'Carga horária usada para a liberação
da disciplina curricular' será útil para o entendimento do campo.

Versão: 2.0.0 Página 5 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

COMMENT ON TABLE Tabela IS 'Descrição do comentário';

COMMENT ON COLUMN Tabela.Coluna IS 'Descrição do comentário';

2.2. Coluna

É um item de dados do registro, com um nome e um tipo associado, as colunas de uma tabela são
também conhecidas por campos ou atributos.
Quando o conteúdo de uma coluna for letras, esse conteúdo deve ser armazenado em maiúsculo.
Essa regra pode ser validada no BD através de uma constraint específica para a coluna.
Exemplo: coluna SEXO deve conter “M” e “F” maiúsculo.

Padrão de nomenclatura COLUNAS

<PREFIXO>_<NOME DA COLUNA>

 Onde prefixo deve receber um dos seguintes valores:

Prefixo Descrição Exemplo

ID Identificador Único: Utilizado como ID_FUNCIONARIO

prefixo de chave primária ou chave
estrangeira. Código interno do sistema,
gerado normalmente através de sequences.

CD Código externo conhecido pelo CD_MATRICULA,

usuário. Campos que possuem dígito
CD_DISCIPLINA,
verificador também devem ser prefixados
por CD CD_UNIDADE,
CD_CONTA,
CD_AGENCIA,
CD_BANCO,
CD_IP,
CD_CURRICULO,
CD_CPF

NM Nome: Prefixo atribuído aos dados NM_FUNCIONARIO,

de natureza alfabética ou alfanumérica cujo
NM_RUA
conteúdo expressa uma denominação por
extenso; composta de palavras,
abreviaturas ou ambas. 

TX Texto genérico: Prefixo atribuído TX_OBSERVACAO,

aos dados de natureza alfanumérica cujo

Versão: 2.0.0 Página 6 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

conteúdo é livre e em forma discursiva TX_DESCRICAO,

como descrições e observações.
TX_EMAIL

SG Sigla: Prefixo atribuído aos dados SG_UF,

que expressam a forma sintética de um
SG_PAIS
conteúdo extenso através de abreviaturas
SG_CURRICULO***
***exceção, pois já existe o
CD_CURRICULO, que é um
código interno do sistema e
deveria ser ID_CURRICULO

NR Número: Prefixo atribuído aos NR_HORAS_AULA,

dados de natureza numérica cuja
NR_RG,
identificação se faz por valores. No caso de
telefones, deve-se criar 3 atributos NR_TELEFONE,
separados: NR_TELEFONE, NR_DDD,
NR_DDD,
NR_DDI, todos numéricos.
NR_DDI,
NR_OPERADOR

VL Valor: Prefixo atribuído aos dados VL_INSCRICAO

de natureza numérica que expressam uma
importância monetária. 

ST Status: Prefixo de coluna que indica ST_ATIVO

o estado temporário de um objeto (espera-
se que o atributo sofra mudanças no
decorrer do uso do sistema). Exemplo:
ST_MATRICULADO (S/N),
ST_SOLICITACAO
(ABERTA/FECHADA/PENDENTE) 

TP Tipo: Prefixo de coluna utilizado em TP_ENDERECO,

campos que expressam uma lista de
TP_SEXO
valores pré-definida, e que não se espera
que mude.

DT Data: Atribuída aos dados de DT_INICIO

natureza numérica que expressam o dia,
mês e ano no calendário civil.

HR Hora: Atribuída aos dados de HR_INICIO,

natureza numérica que expressam um
HR_FIM
horário hh24:mi:ss.

BL Blob: Usado, por exemplo, no BL_ARQUIVO

armazenamento de arquivos/documentos
digitalizados.

 Onde nome coluna deve receber um nome significativo que reflita claramente o conteúdo que deve ser
armazenado na coluna. Evitar nomes redundantes que não agregam valor, por exemplo: NM_NOME,

Versão: 2.0.0 Página 7 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

ST_STATUS

2.3. Constraint

São restrições estabelecidas para uma coluna do BD, e podem ser dos seguintes tipos:
 Primary Key (Chave primária): coluna ou conjunto de colunas que servem para definir de forma
única um registro na tabela. Uma coluna de chave primária não pode conter valores nulos nem pode
conter valores repetidos, isto é, ela identifica cada registro dando-lhe unicidade.

 Foreign Key (Chave estrangeira): determina uma coluna ou um conjunto de colunas que possuem
valores em outras tabelas, referente a um relacionamento. Ela verifica se o valor referido ao atributo
já foi inserido na tabela base (origem).

 Unique Key (Chave única): é uma coluna que obedeça à restrição de unicidade, isto é, não pode
ter valores repetidos. Contudo, pode conter valores nulos.

 Check Constraint: é possível obrigar que na inserção de dados sejam verificadas condições, sendo
a inserção de dados realizada somente se o valor devolvido for verdade ou desconhecido no caso de
existir comparações com valores nulos. As condições podem incluir expressões aritméticas e
chamadas de funções SQL.

Utilize check constraint quando uma coluna possuir uma lista de valores pré-definida (com poucos
valores e estáveis) e a coluna não admitir ocorrência de valor nulo.
Exemplo: SEXO CHAR(1) NOT NULL CONSTRAINT CK_PG_SEXO CHECK (TP_SEXO IN ('F','M')).

Padrão de nomenclatura CONSTRAINT

Constraint padrão <TIPO OBJETO> _<SIGLA SISTEMA>_ <NOME

TABELA>_<NUM>

Constraint para Foreign key: utilize dois <TIPO OBJETO>_<SIGLA SISTEMA>_<NOME TABELA
sublinhados (__) para separar as tabelas de DESTINO>__<NOME TABELA ORIGEM>_ <NUM>:. Exemplo:
destino (filha) e origem (pai). FK_SIM_INDICADOR__ACAO.

Legenda:
<TIPO OBJETO>:
o PK para primary key;

Versão: 2.0.0 Página 8 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

o UK para unique key;

o FK para foreign key;
o CK para check constraint;
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME TABELA>, <NOME TABELA DESTINO> e <NOME TABELA ORIGEM>: nome da tabela
relacionado ao objeto;
<NUM>: número sequencial para distinguir os diversos tipos de objeto, utilize se necessário.

2.4. Trigger

É um tipo especial de procedimento armazenado no banco de dados, que é executado sempre que
há uma tentativa de modificar os dados de uma tabela. Quando há uma tentativa de inserir, atualizar ou
excluir os dados em uma tabela, e uma Trigger tiver sido definida na tabela para essa ação específica, ela
será executada automaticamente, não podendo nunca ser ignorada.
Ao criar triggers tenha cuidado para manter a coerência com o tipo correto <TIPO TRIGGER>. Atente
aos os eventos que disparados pela trigger.
 Before: onde os campos :old e :new podem ser lidos e alterados;
 After: onde os campos :old e :new podem somente ser lidos.
 Instead Of; usada para manipular views não atualizáveis.

Comando para triggers de consistências em colunas específicas:

Create trigger TRG _<SIGLA SISTEMA>_ <NOME TABELA ALTERADA>_<NUM>_BU
Before update
Of <NOME_COLUNA>
On <NOME_TABELA>

Padrão de nomenclatura TRIGGERS

TRG _<SIGLA SISTEMA>_ <NOME TABELA ALTERADA> _<NUM>_<TIPO DE TRIGGER>

Legenda:
TRG : representa um objeto do tipo trigger;
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME TABELA ALTERADA>: nome da tabela alterada, sobre a qual a trigger se referencia;
<NUM>: número sequencial para distinguir os diversos tipos de objeto, se necessário;
<TIPO DE TRIGGER>: conforme padrões descritos abaixo

Versão: 2.0.0 Página 9 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

Tipo Trigger Finalidade Exemplo

AI After Insert TRG_PG_CURSO_AI

AD After Delete TRG_ PG_CURSO_AD
AU After Update TRG_PG_CURSO_AU
AID After Insert ou Delete TRG_PG_CURSO_AID
AIU After Insert ou Update TRG _PG_CURSO_AIU
AUD After Update ou Delete TRG_PG_CURSO_AUD
AIUD After Insert ou Update ou Delete TRG _PG_CURSO_AIUD
BI Before Insert TRG _PG_TURMA_BI
BD Before Delete TRG_PG_TURMA_BD
BU Before Update TRG_PG_TURMA_BU
BID Before Insert ou Delete TRG_PG_TURMA_BID
BIU Before Insert ou Update TRG_PG_TURMA_BIU
BUD Before Update ou Delete TRG_PG_TURMA_BUD
BIUD Before Insert ou Update ou Delete TRG_PG_TURMA_BIUD
II Instead of Insert TRG _PG_TURMA_II
ID Instead of Delete TRG_PG_TURMA_ID
IU Instead of Update TRG_PG_TURMA_IU
IID Instead of Insert ou Delete TRG_PG_TURMA_IID
IIU Instead of Insert ou Update TRG_PG_TURMA_IIU
IUD Instead of Update ou Delete TRG_PG_TURMA_IUD
IIUD Instead of Insert ou Update ou Delete TRG_PG_TURMA_IIUD

2.5. View

É uma representação virtual de uma tabela, pois não possui linhas próprias, mas sim as obtém em
tempo de execução e as disponibiliza em memória para acesso por uma query. Este objeto tem suas linhas e
colunas calculadas dinamicamente através de um SELECT pré-estabelecido, cada vez que solicitamos. Pode
conter colunas de uma ou várias tabelas físicas ou até mesmo de outras Views.
Uma View funciona de forma semelhante a uma tabela, sendo possível utilizá-la em qualquer lugar
onde se possa utilizar uma tabela.
Ao criar uma view, lembre-se:
 Crie-as com funções específicas, mesmo que para isso precise criar mais de uma view;
 Tenha cuidado no uso de views encadeadas (view que chama outra view), pois isso afeta
consideravelmente o desempenho;

Versão: 2.0.0 Página 10 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

 Otimize as querys a serem utilizadas, caso a query possua mais de uma tabela utilize aliás.
 Siga as orientações do item 2.2 para as colunas

Padrão de nomenclatura VIEW

VW _<SIGLA SISTEMA>_ <NOME VIEW>

Legenda:
VW: representa um objeto do tipo view;
<SIGLA SISTEMA>: ser formada por 2 ou 3 letras;
<NOME VIEW>: nome significativo que reflita claramente o conteúdo que será trazido por ela.

2.6. Materialized View

São utilizadas para fazermos cálculos, armazenamentos de dados e dar agilidade na troca de
informações entre um BD ou entre tabelas, com o seu uso é possível melhorar o desempenho do sistema.

Padrão de nomenclatura MATERIALIZED VIEW

MV _<SIGLA SISTEMA>_ <NOME MATERIALIZED VIEW>

Legenda:
MV: representa um objeto do tipo materialized view;
<SIGLA SISTEMA>: ser formada por 2 ou 3 letras;
<NOME MATERIALIZED VIEW>: nome significativo que reflita claramente o conteúdo que será
trazido por ela.
2.6.1. Sequence

É um objeto com estrutura de dados independente utilizado para gerar uma sequência de valores.
Sua utilização como Primary Key facilita a manutenção do modelo de dados no caso de alteração na chave de
negócio.
Ao criar uma sequence, lembre-se:
 Devem sempre ser lidas na trigger de insert;
 Cuidado ao utilizar o parâmetro nocache, pois apresentarão pior performance (gera mais I/O
para atualizar o dicionário de dados);
 Em ambientes RAC, que é o nosso caso, sequences com a cláusula order apresentam pior
performance, pois os valores das sequences precisam ser sincronizados entre os nós do RAC,
através de um serviço global de cache, no qual ocorre o evento chamado global lock.

Padrão de nomenclatura SEQUENCE

Versão: 2.0.0 Página 11 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

SQ _<SIGLA SISTEMA>_ <NOME TABELA>_<NUM>

Legenda:
SQ: representa um objeto do tipo sequence;
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME TABELA>: receber o nome da tabela que se referência com esta sequence;
<NUM>: número sequencial para distinguir sequences que tenham o mesmo nome.

2.7. Índice

É uma estratégia de otimização de consultas, os índices funcionam como catálogos organizados de

forma a beneficiar certo tipo de consulta. Um índice permite que o conjunto das linhas de uma tabela que
satisfazem determinado critério seja localizado rapidamente. A chave primária de uma tabela é um índice.
Ao criar índices compostos lembre-se, a ordem das colunas deve ser da mais utilizada para a menos
utilizada. Tabelas de LOG não precisam de índice.

Padrão de nomenclatura ÍNDICE

IND _<SIGLA SISTEMA>_ <NOME TABELA>_<NUM>

Legenda:
IND: representa um objeto do tipo índice;
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME TABELA>: nome da tabela que se referência com este índice;
<NUM>: um número sequencial para distinguir os diversos índices de uma tabela.

2.8. Function, Stored Procedure e Package

 Function (função): é uma função armazenada no BD que pode ser chamado de dentro do próprio
Oracle ou a partir de alguma linguagem de programação, via ODBC/JDBC. Funções sempre retornam
um valor a quem as chamou.

 Stored Procedure (procedimento): é um procedimento armazenado no BD que pode ser chamado

de dentro do próprio Oracle ou a partir de alguma linguagem de programação, via ODBC/JDBC.

Versão: 2.0.0 Página 12 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

 Package (pacote): é um objeto do banco de dados capaz de armazenar procedimentos e funções

juntas que podem ser executadas separadamente como se fossem parte de uma biblioteca ou a
partir de uma execução provocar várias execuções encadeadas.

No uso de Function, Stored Procedure e Package defina uma área de identificação geral do objeto,
onde deverão existir informações tais como: Autor, Data, Função/Objetivo.

Padrão de nomenclatura FUNCTION/ STORED PROCEDURE / PACKAGE / TYPE

<TIPO OBJETO>_<SIGLA SISTEMA>_ <NOME OBJETO>

Legenda:
<TIPO OBJETO>:
o FUN para function.
o PRD para procedure.
o PKG para package.
o TP para tipos.
<SIGLA SISTEMA>: formada por 2 ou 3 letras;
<NOME OBJETO>: nome significativo que reflita claramente o conteúdo que deve ser armazenado no
objeto.

2.9. Conceitos e características de LOG e HISTÓRICO

LOG HISTÓRICO
C

 Registro das transações efetuadas no  Registro temporal das informações de

banco de dados negócio.

 Voltado para o negócio.

Características

 Voltado para a Tecnologia (Segurança).  Consultado pelo Gestor do Negócio.

 Consultado para fins de Auditoria.
 O tempo de resposta não é relevante.
 Normalmente, é pouco acessado.
 O acesso pode ser batch.
 O tempo de resposta é relevante.
 Normalmente, é acessado com frequência.
 O acesso é on-line.
 Pode ser usado para geração de
estatísticas.

Versão: 2.0.0 Página 13 de 15

 PUCRS - Uso Restrito
Padrões de Nomenclatura para Objetos de
Banco de Dados

3. Histórico de Revisões

Data Versão Descrição Autor

16/05/2007 1.0.0 Criação do Documento Cláudia Rocha
23/10/2014 2.0.0 Revisão dos padrões de nomenclatura Camila Conti, Douglas Oliveira,
objetos de banco de dados. Destaques para: Evandro Esteves, Leonardo
Panatta, Loraine Pivatto, Patrick
 Remoção do prefixo padrão de colunas
Santos, Marcelo Yamaguti,
de tabelas.
Roberto Schroeder, Sandro
 Ordenação alfabética do tipo de Trigger. Kowalczuk.
 Padrão de nomenclatura das tabelas
LOG e TEMP com sufixo identificador.
 Orientação do formato de tabelas de
LOG.
Julho/agosto 3.0.0 Reformulação do padrão de nomes de Henrique Becker, Loraine
de 2015 colunas Pivatto, Evandro Esteves, Camila
Conti.
Outubro/2015 4.0.0 Atualização no padrão de colunas. Inclusão Loraine Pivatto, Evandro
do prefixo HR e da exceção SG_CURRICULO Esteves, Henrique Becker,
para o que deveria ser CD_CURRICULO, pois Heloísa Ackermann.
já existe um CD_CURRICULO usado como
código interno do sistema.

Loraine Pivatto, Evandro

Correção também na nomenclatura das
Esteves, Henrique Becker,
triggers, incluindo a Instead of
Rodrigo Fehse
20/11/15 5.0.0 Alteração na nomenclatura das triggers, Loraine Pivatto, Evandro
deixando a sigla na ordem IUD Esteves, Henrique Becker,
Heloísa Ackermann, Camila
Conti.
22/11/2018 5.0.1 Inclusão da formatação da PK, já enviada por Pedro Fontoura
e-mails em 19/02/2018
10/12/2018 5.0.2 Inclusão de informações sobre os Pedro Fontoura
comentários em tabelas e colunas
26/03/2019 5.0.3 Inclusão do type no item 2.8 Pedro Fontoura

Versão: 2.0.0 Página 14 de 15