Padroes BD

Table of Contents
Padrões para Banco de Dados Relacional.............................................................................................1

1 - Projeto Conceitual.....................................................................................................................1
1.1 Colaboradores:....................................................................................................................1
1.2 Homologação:....................................................................................................................1
1.3 Padrões para criação do MER no Oracle Designer:...........................................................1
1.3.1 Container...................................................................................................................1
1.3.2 Diagrama do MER ou no MD...................................................................................2
1.3.3 Entidades:..................................................................................................................2
1.3.4 Relacionamentos.......................................................................................................4
2 - Projeto Lógico...........................................................................................................................4
3 - Projeto Físico.............................................................................................................................4
3.1.1 Tabelas:...........................................................................................................................4
3.1.2 Colunas.....................................................................................................................4
3.1.3 View..........................................................................................................................5
3.1.4 Primary Key..............................................................................................................5
3.1.5 Unique key................................................................................................................6
3.1.6 Foreign Key..............................................................................................................6
3.1.7 Check Constraints.....................................................................................................7
3.1.8 Sequence...................................................................................................................8
3.1.9 Índices.......................................................................................................................8
3.1.10 Triggers...................................................................................................................9
3.1.11 Stored Procedure.....................................................................................................9
3.1.12 Function (Função).................................................................................................10
FAQ sobre as abreviações que constam no início do nome de cada atributo...............................11
1 - Qual a diferença entre CODG e NUMR?.........................................................................11
2 - Quando usar NOME, DESC e INFO?..............................................................................11
3 - Quando utilizar PERC e VALR?......................................................................................11
4 - Quando usar STAT, TIPO e INDI?..................................................................................11
5 - ID é sempre utilizado para PK?........................................................................................11
6 - REFE.................................................................................................................................11
7 - MATR...............................................................................................................................11
8 - USER................................................................................................................................12
9 - HORA...............................................................................................................................12
10 - Dúvidas?..........................................................................................................................12
i
Padrões para Banco de Dados Relacional
1 - Projeto Conceitual
Determina a implementação das informações no Modelo de Entidade e Relacionamento (MER) ou do
Modelo Dimensional (MD) na ferramenta Oracle Designer.
1.1 Colaboradores:
Administradores de Dados, Analistas de Negócios, Analistas de Sistemas, Analistas de Dados, Analistas de

Business Intelligence.
1.2 Homologação:
Apresentação do MER ou do MD para os Administradores de Dados da Gerência de Infraestrutura Técnica

na Supervisão de Banco de Dados (GIT-SUPBD), para devida integração e homologação do modelo.
1.3 Padrões para criação do MER no Oracle Designer:
1.3.1 Container
Para o nome do container no Oracle Designer deverá ser utilizado o seguinte padrão:
SiglaSistema: Sigla do sistema composta por três letras e deverá ser validada e cadastrada junto a
GIT-SUPBD. O cadastro de siglas é feito na ferramenta WEBTOOLS.
No campo "Title" colocar o nome do sistemas.
Caso hajam informações relevantes para documentar sobre o container, colocar no campo "Comment".
Internamente, cada container deverá ter duas subpastas, a saber:
SiglaSistema_Conceitual: Conterá a documentação de todos os objetos do modelo Conceitual do sistema:
SiglaSistema_Físico: Conterá o modelo lógico do sistema já contendo os objetos da forma como deverão ser
criados no modelo físico.
OU
SiglaSistema_DW_Conceitual: Para projetos de BI, conterá a documentação de todos os objetos do modelo

Conceitual do sistema:
SiglaSistema_DW_Físico: Para projetos de BI, conterá o modelo lógico do sistema já contendo os objetos
da forma como deverão ser criados no modelo físico.
Exemplos:
ARR_CONCEITUAL
ARR_DW_CONCEITUAL
GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 1

$LOGOIMAGE l l 13 Dec 2018 - 10:39
1.3.2 Diagrama do MER ou no MD
Para o nome do diagrama no MER deverá ser utilizado o seguinte padrão:
MER_Sigla_Sistema_Descritivo
Onde:
Descritivo: Nome do módulo ou do sistema ao qual se refere o modelo de dados.
Exemplos: MER_CGO_ORGANIZACAO_ADMINISTRATIVA
MER_CGO_PESSOA_JURIDICA
Para o nome do diagrama no MD deverá ser utilizado o seguinte padrão:
Utilizar o mesmo nome da tabela fato do diagrama:
Exemplo: FT_SRH_REMUNERACAO_ORGAO
Para os casos nos quais os diagramas refiram-se exclusivamente à tabelas dimensões, utilizar o nome da
tabela dimensão principal ou final, em uma cadeia de relalcionamentos.
Exemplo: DM_SRH_RUBRICA
DM_NFE_NOTA_FISCAL_ELETRONICA
1.3.3 Entidades:
Para o nome das entidades deverá ser utilizado o seguinte padrão:
* MER - Modelo Entidade Relacionamento*
SiglaSistema_Descritivo
Onde:
Descritivo: Nome no singular que defina com clareza o significado da Entidade. Evitar colocar a
palavra TIPO no nome da entidade. Quando for realmente necessário, não usar nas colunas os
prefixos CODG e NUMR, usar o prefixo TIPO.
* MD - Modelo Dimensional*
SiglaSistema_DM_Descritivo OU SiglaSistema_FT_Descritivo
DM Para entidade que será uma tabela Dimensão
FT Para entidade que será uma tabela Fato

Descritivo: Nome no singular que defina com clareza o significado da Entidade. Evitar colocar a
palavra TIPO no nome da entidade. Quando for realmente necessário, não usar nas colunas os
prefixos CODG, NUMR E NOME.
Exemlos adequados: TIPO_DOCUMENTO, DESC_TIPO_DOCUMENTO
Exemplos inadequados: CODG_TIPO_DOCUMENTO, NUMR_TIPO_DOCUMENTO,

NOME_TIPO_DOCUMENTO
1.3.3.1 Considerações Gerais:
• Não devem ser utilizados caracteres característicos da língua portuguesa como acentos e cedilha.
• Na formação dos nomes não devem ser utilizadas conjunções e preposições como de, da, do, para,
etc.
• Todas as palavras que compuserem os nomes das entidades deverão estar em letras maiúsculas.
• Não há obrigatoriedade de abreviar palavras mesmo que sejam maiores que dez (10) caracteres.
• Na parte descritiva as palavras devem ser definidas no singular.
• O nome da Entidade (SiglaSistema_Descritivo) não poderá exceder o limite de trinta (30) caracteres,
devido à limitações do banco de dados.
• Caso alguma palavra que compõe a parte descritiva necessite ser abreviada em decorrência do
tamanho limite de 30 caracteres, deverá ser utilizado o mnemônico da palavra, conforme padrão
adotado em Mnemônicos na aplicação WEBTOOLS
• No caso de abreviação, pode ser abreviada qualquer palavra que faça parte do nome da entidade
atentando para que o nome fique o mais significativo possível.
• Cada entidade deverá ter um Shortname único, independente do sistema ao qual pertença. O
Shortname será criado pela GIT-SUPBD e deverá ser definido baseado nas abreviações contidas em
Shortname de Colunas na aplicação WEBTOOLS. O shortname servirá como base para criação de
objetos relacionadas à entidade no banco de dados.
• Na definição da entidade os campos Name e Plural deverão ter o mesmo nome.
• Todas as entidades deverão ter sua descrição bem detalhada no campo TEXT na aba
DESCRIPTION. O campo NOTES, da mesma aba, também pode ser utilizado para acrescentar mais
informações que sejam relevantes sobre a entidade.
1.3.3.2 Atributos
Para o nome dos atributos deverá ser utilizado o seguinte padrão:
AAAA_DESCRITIVO
Onde:
AAAA:
Abreviação indicando o tipo do campo conforme padrão definido. As abreviações utilizadas são:
CODG, NUMR, DATA, NOME, DESC, INFO, PERC, QTDE, STAT, TIPO, VALR, INDI, MATR, ID,
REFE, HORA, SIGL.
No final deste documento consta uma FAQ sobre quando utilizar cada uma dessas abreviações.
DESCRITIVO:
Nome que define o significado da coluna.
• Não devem ser utilizados caracteres característicos da língua portuguesa como acentos e cedilha.
• Na formação dos nomes, não devem ser utilizadas conjunções e preposições como de, da, do, para,
etc.
• Todas as palavras que formam os nomes dos atributos deverão estar em letras maiúsculas.
• Se na parte descritiva do nome houver mais de uma palavra deverá ser utilizado o símbolo
underscore ( _ ) para separar as mesmas.
• Na parte descritiva as palavras devem ser definidas no singular.
• Toda palavra menor ou igual a dez (10) caracters que compuser a parte descritiva deverá ser utilizada
sem nenhum tipo de abreviação. Será permitido a abreviação de palavras até dez (10) caracteres
somente quando, apesar das abreviações possíveis haverem sido feitas, o nome total da coluna
continuar maior que trinta (30) caracteres. Nesse caso deverá ser abreviada da última para a primeira
palavra utilizando o padrão adotado em Shortname de Colunas , na aplicação WEBTOOLS.
• Toda palavra maior que dez (10) caracteres que compuser a parte descritiva deverá ser abreviada de
acordo com as abreviações constantes em Mnemônicos na aplicação WEBTOOLS.
• Os nomes das colunas não poderão exceder o limite de trinta (30) caracteres, devido à limitações do
banco de dados. Caso esse limite seja excedido, deve-se verificar a possibilidade de retirar alguma
palavra de forma que o significado do nome não seja prejudicado. Caso não seja possível retirar uma
palavra do nome, então deverão ser utilizadas abreviações mesmo nas palavras com até dez (10)
caracteres, começando a abreviar da última para a primeira palavra até que o tamanho fique igual ou
menor que 30 caracteres.
• Em caso de nomes que possuem siglas já conhecidas, deve ser utilizada a própria sigla para
composição do nome da coluna. (CFOP, CNAE, UF, CNPJ, etc.). Exemplo: CODG_UF ao invés de
CODG_UNIDADE_FEDERACAO.
• Todos os atributos deverão ter sua descrição bem detalhada no campo COMMENT do atributo.
1.3.4 Relacionamentos
A finalidade do relacionamento deve ser descrita no campo TEXT. Na geração do modelo lógico, essa
descrição deverá ser utilizada para descrever a coluna FK.
2 - Projeto Lógico
É gerado pelos Administradores de Dados da GIT-SUPBD a partir do MER homologado. Nesse
modelo os nomes de entidades e colunas criados no modelo conceitual serão mantidos. Novos
nomes devem ser criados somente para colunas chaves estrangeiras que possuem mais de um
relacionamento com uma mesma tabela.
Para os índices, Foreign Keys, Primary Keys, Unique Keys, Constaints, Views, Triggers e Sequences, os
shortnames deverão ser utilizados conforme descrito no item 3 Projeto Físico.
3 - Projeto Físico
Gerado pelos Administradores de Banco de Dados da GIT-SUPBD a partir do Projeto Lógico. O modelo
físico trata da criação de todos os objetos no banco de dados.
3.1 Padrão de Nomes para os Objetos de Banco de Dados:
3.1.1 Tabelas:
Obrigatoriamente a tabela deve ter o mesmo nome que a tabela correspondente no modelo lógico.
3.1.2 Colunas
Obrigatoriamente a coluna deverá ter o mesmo nome que a coluna correspondente no modelo lógico.

3.1.3 View
As views deverão ser descritas e documentadas no Oracle Designer.
Para o nome de Views deverá ser utilizado o seguinte padrão:
SiglaSistema_Descritivo
Onde:
SiglaSistema: Sigla do sistema que utilizará a view, ou, sendo considerada corporativa, deverá ser utilizada a
sigla CGO.
Descritivo: Nome no singular que defina com clareza o significado da View. Não utilizar a palavra
VIEW para compor o nome.
• Os padrões para nomes de views devem seguir o mesmo descrito nesse documento nos itens 1.3.1 e
1.3.1.1.
• Todas as palavras que formam os nomes dos atributos deverão ser em letras maiúsculas e deverão
seguir os padrões definidos nos itens 1.3.1.2 e 1.3.1.3. Exceção somente quando for necessário criar
uma view com os nomes de colunas baseadas em tabelas com nomes em padrões antigos. Sempre
que possível, os nomes das colunas da view são os mesmos das colunas correspondentes das tabelas
origem.
3.1.3.2 Exemplos:
Views criadas a partir da tabela GEN_UNIDADE_OPERACIONAL:
a) GEN_UNIDADE_OPERACIONAL_SEFAZ
Onde:
GEN: Identificador do sistema

UNIDADE_OPERACIONAL_SEFAZ: Nome no singular que define o significado da VIEW
b) GEN_UNIDADE_OPERC_EXTERNA
Onde:
GEN: Identificador do sistema

UNIDADE_OPERC_EXTERNA: Nome no singular que define o significado da VIEW
3.1.4 Primary Key
Para o nome da Primary Key deverá ser utilizado o seguinte padrão:
ShortName_IdentificadorObjeto
Onde:
ShortName:
É o ShortName da tabela
IdentificadorObjeto:

Deverá ser informado a sigla PK identificando que é um objeto do tipo Primary Key.
• Toda tabela deverá ter uma PK, preferencialmente com uma única coluna. Se isso não for possível,
uma UK gerada através de auto incremento deverá ser criada para que possa atender aos requisitos de
histórico/auditoria.
3.1.4.2 Exemplo:
a)
MUNIC_PK -> Primary Key da tabela GEN_MUNICIPIO

Onde:
MUNIC: ShortName da tabela;
PK: Sigla que identifica o objeto Primary Key no banco de dados;
3.1.5 Unique key
Para o nome de Unique Key (chaves únicas) deverá ser utilizado o seguinte padrão:
ShortName9_IdentificadorObjeto
Onde:
ShortName:
É o ShortName da tabela.
9:
Um número seqüencial para identificar a Unique Key Constraint para o caso em que haja mais de
uma UK para a mesma tabela.
Deverá ser informado o sigla UK identificando que é um objeto do tipo Unique Key Constraint.
3.1.5.1 Exemplo:
PESSOA1_UK -> Unique Key Constraint da tabela GEN_PESSOA.

PESSOA2_UK -> Unique Key Constraint da tabela GEN_PESSOA.
CONTRIB1_UK -> Unique Key Constraint da tabela CCE_CONTRIBUINTE.
3.1.6 Foreign Key
Para o nome de Foreign Key deverá ser utilizado o seguinte padrão:
ShortNameTabelaFilha_ShortNameTabelaPai9_IdentificadorObjeto
Onde:
ShortNameTabelaFilha:
É o ShortName da tabela filha

ShortNameTabelaPai:
É o ShortName da tabela pai
9:
Utilizado no caso de uma tabela filha ter mais de um relacionamento com uma mesma tabela pai. É um
número crescente para identificar a foreign key para a referida tabela.
Deverá ser informado a sigla FK identificando que é um objeto do tipo Foreign key.
3.1.6.1 Exemplo:
CONTRIB_PESSOA1_FK -> FK criada entre a tabela filha CCE_CONTRIBUINTE e a pai GEN_PESSOA

Onde:
CONTRIB: ShortName da tabela filha;

PESSOA: ShortName da tabela pai;
1: Identificador seqüencial das foreign keys da tabela filha;
FK: Sigla que identifica o objeto foreign key no banco de dados;
3.1.7 Check Constraints
Para o nome das Check Constraints deverá ser utilizado o seguinte padrão:
ShortName_NomeColuna_IdentificadorObjeto
Onde:
ShortName:
É o ShortName da tabela;
NomeColuna:
Nome da coluna para a qual esta sendo criada a Check Constraint;
Deverá ser informado a sigla CK identificando que é um objeto do tipo Check Constraint;
• Caso não seja possível manter aqui o nome completo da coluna devido a restrição de trinta caracteres
no nome total, então este deve ser abreviado seguindo o padrão definido no item 1.3.1.3, deste
documento.
• Para toda coluna associada a um domínio específico, deve ser criada uma Check Constraint seguindo
este mesmo padrão.
• Por via de regra, para os Modelos de Dados Dimensionais não há necessidade de criar Constraints ou
Domínios, a menos que seja explicitamente solicitado.
3.1.7.2 Exemplo:
PESSOA_TIPO_PESSOA_CK ->

Check Constraint para a coluna TIPO_PESSOA da tabela

GEN_PESSOA.
Onde:
PESSOA: É o ShortName da tabela;

TIPO_PESSOA: Nome da coluna que está sendo referenciada na Check Constraint;
CK: Identificador do objeto check constraint;
3.1.8 Sequence
Para o nome de Sequences deverá ser utilizado o seguinte padrão:
ShortName_IdentificadorObjeto
Onde:
ShortName:
Deverá ser informada a sigla SQ identificando que é um objeto do tipo Sequence.
• Sequences são criadas e associadas a colunas do tipo ID que são PKs ou UKs nas tabelas. A partir da
versão 12 do Oracle, não há necessidade de criação da sequence, basta informar que a coluna é
autoincremento e o próprio banco se encarregará de criar a sequence.
3.1.8.2 Exemplos:
ENDERECO_SQ -> Sequence para ser utilizado no ID da tabela GEN_ENDERECO.

PESSOA_SQ -> Sequence para ser utilizado no ID da tabela GEN_PESSOA.
3.1.9 Índices
Para o nome dos índices deverá ser utilizado o seguinte padrão:
Onde:
ShortName:
É o ShortName da tabela;
9:
Um número seqüencial para identificar o índice para a referida tabela;
Deverá ser informada a sigla IX identificando que é um objeto do tipo Índice;

• No caso de índices para Primary Key e Unique key Constraint, não há necessidade da criação de um
objeto tipo IX, pois os objetos tipo PK ou UK já identificam os índices.
3.1.9.2 Exemplo:
a)
MUNIC2_IX -> índice da tabela GEN_MUNICIPIO

Onde:

2: número seqüencial identificando o índice da tabela;
IX: identificador do objeto índice no banco de dados;
b)
MUNIC_PK -> índice da Primary Key da tabela GEN_MUNICIPIO

Onde:

PK: identificador do objeto índice da primary key da tabela no banco de dados;
3.1.10 Triggers
Para o nome de triggers deverá ser utilizado o seguinte padrão:
Onde:
ShortName:
9:
Um número sequencial para identificar a trigger para a referida tabela;
Deverá ser informada a sigla TR identificando que é um objeto do tipo Trigger.
3.1.10.1 Exemplo:
ENDERECO1_TR -> Trigger da tabela GEN_ENDERECO.

Onde:
ENDERECO: ShortName da tabela;

1: número seqüencial identificando a trigger da tabela;
TR: identificador do objeto trigger no banco de dados;
3.1.11 Stored Procedure
Para o nome de stored procedures deverá ser utilizado o seguinte padrão:
IdentificadorObjeto_SiglaSistema _DESCRITIVO

Onde:
Deverá ser informada a sigla SP identificando que é um objeto do tipo Stored Procedure.
SiglaSistema:
Sigla do sistema a qual pertence o objeto.
Descritivo:
Nome no singular que defina com clareza o propósito do objeto. Caso haja mais de uma palavra no nome,
estas deverão ser separadas por underline ( _ ).
• Entre IdentificadorObjeto? e SiglaSistema? não há espaços.

• Para stored procedures de uso geral, utilizar a sigla CGO como sigla do sistema.
3.1.11.2 Exemplo:
SPGAF_GRAVA_PROCESSO -> Procedure do sistema GAF que faz gravação de processo.

SPCTE_ EQUIPTO_PENDENCIA -> Procedure do sistema CTE que verifica as pendências dos
equipamentos cadastrados.
3.1.12 Function (Função)
Para o nome de functions deverá ser utilizado o seguinte padrão:
IdentificadorObejto _DESCRITIVO
Onde:
Deverá ser informada a sigla SPF identificando que é um objeto do tipo Function.
Descritivo:
Nome no singular que defina com clareza o propósito do objeto. Caso haja mais de uma palavra no nome,
estas deverão ser separadas por underline ( _ )
• Entre IdentificadorObjeto? e SiglaSistema? não há espaços.

• Para functions de uso geral, utilizar a sigla CGO como sigla do sistema.
3.1.12.2 Exemplo:
SPF_GERA_DV_CPF -> Função que gera digito verificador do CPF.

SPF_ANO_BISSEXTO Função que verifica se o ano é bissexto.

FAQ sobre as abreviações que constam no início do nome de cada

atributo.
1 - Qual a diferença entre CODG e NUMR?
Quando usar cada uma dessas abreviações está mais relacionado à forma como o atributo é conhecido no
mundo real. Por exemplo: não é comum alguém falar código da matrícula do funcionário e sim número da
matrícula do funcionário. Da mesma forma, não é comum falar código do CPF e sim, número do CPF. Não
necessariamento NUMR tem que ser usado para colunas do tipo numérico.
2 - Quando usar NOME, DESC e INFO?
Mais uma vez vale o bom senso em relação ao mundo real. O NOME nomeia uma pessoa, bairro, município,
país, estado, etc.. DESC é sempre usado para descrever alguma coisa e não nomear. Exemplo: descrição de
uma meta, um objetivo, um resultado, uma situação, um tipo, uma fórmula, etc. Podem aparecer casos em
que tenhamos na mesma entidade NOME e DESC. INFO é mais utilizado como uma observação ou um
complemento da informação.
3 - Quando utilizar PERC e VALR?
PERC deve ser utilizado quando a informação a ser armazenada é somente um percentual de um determinado
valor. Apesar de um percentual ser um valor, a abreviação PERC fica mais significativa. VALR é utilizado
para todos os campos que indiquem valores e que não sejam somente um valor percentual. Podem ocorrer
casos em que um atributo iniciado com VALR ser alfanumérico.
4 - Quando usar STAT, TIPO e INDI?
TIPO é sempre utilizado em tabelas básicas de tipo de alguma coisa , exemplo: tipo de documento. Outra
utilização para TIPO é quando essa tabela básica for colocada no modelo de dados em forma de domínio de
um campo. STAT sempre indica situação de alguma coisa. Exemplo: situação cadastral (ativo, suspenso,
baixado), situação da remessa (enviada, recebida), situação do documento (aberto, fechado, bloqueado).
INDI sempre indica um indicador de SIM ou NÂO, ATIVO ou INATIVO, NACIONAL ou MUNICIPAL ou
ESTADUAL.
5 - ID é sempre utilizado para PK?
ID deve ser utilizado somente para atributos gerados automaticamente pelo banco de dados, para tal, sempre
estão associados a um objeto tipo Sequence e a outro tipo Trigger para o controle do autoincremento. A partir
da versão 12 do Oracle, não há necessidade da criação de sequence e trigger associados à coluna que inicia
por ID, basta informar que a coluna é utoincremento. Normalmente é o campo chave da entidade/tabela. Se o
autoincremento da coluna for controlado pela aplicação, seu nome deve começar com outro prefixo,
geralmente NUMR.
6 - REFE
Deve ser utilizado quando indicar uma referência ANO_MÊS, ou seja, não é uma data completa.
Campos desse tipo sempre são number(6).
7 - MATR
Deve sempre ser utilizado para indicar atributos que se referem a uma matrícula. Exemplo: matrícula do
funcionário, matrícula do aluno, etc.

8 - USER
Deve sempre ser utilizado para indicar atributos que se referem ao usuário de login na rede ou do banco de
dados.
9 - HORA
Deve sempre ser utilizado para indicar atributos que armazenarão a informação de hora, sem data. Campos
desse tipo devem ser NUMBER(6) e a informação armazenada no formato HHMMSS, onde:
HH - Hora, com dois dígitos. No caso de hora menor que 10, o zero à esquerda será suprimido por ser um
campo NUMBER. Assim, se for requisito que o zero apareça, a aplicação deverá fazer o devido tratamento.
MM - Minuto, com dois dígitos
SS - Segundo, com dois dígitos
Se houver necessidade de armazenar a informação até o nível de milisegundos, então deve ser utilizado o tipo
TIMESTAMP. Nomes de atributos do tipo TIMESTAMP devem começar com o prefixo DATA.
10 - Dúvidas?
Qualquer dúvida sobre qual a melhor abreviação a ser utilizada pode ser sanada com uma boa descrição sobre
a informação que será armazenada no campo.
This topic: GerenciasSTI/GIT/SBD/BD > PadroesBdr

Topic revision: r21 - 16 Mar 2018 - MariaDeFatimaNeves
Copyright © pelos autores contribuintes. Todo material nessa plataforma colaborativa é propriedade do
Estado de Goiás.
.............................................................................................................................................................................1

Padroes BD

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Padroes BD

Enviado por

Direitos autorais:

Formatos disponíveis

Table of Contents

Padrões para Banco de Dados Relacional.............................................................................................1

Administradores de Dados, Analistas de Negócios, Analistas de Sistemas, Analistas de Dados, Analistas de

Apresentação do MER ou do MD para os Administradores de Dados da Gerência de Infraestrutura Técnica

1.3 Padrões para criação do MER no Oracle Designer:

No campo "Title" colocar o nome do sistemas.

Internamente, cada container deverá ter duas subpastas, a saber:

SiglaSistema_Conceitual: Conterá a documentação de todos os objetos do modelo Conceitual do sistema:

SiglaSistema_DW_Conceitual: Para projetos de BI, conterá a documentação de todos os objetos do modelo

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 1

1.3.2 Diagrama do MER ou no MD

Para o nome do diagrama no MER deverá ser utilizado o seguinte padrão:

Descritivo: Nome do módulo ou do sistema ao qual se refere o modelo de dados.

Para o nome do diagrama no MD deverá ser utilizado o seguinte padrão:

Utilizar o mesmo nome da tabela fato do diagrama:

Para o nome das entidades deverá ser utilizado o seguinte padrão:

* MER - Modelo Entidade Relacionamento*

DM Para entidade que será uma tabela Dimensão

FT Para entidade que será uma tabela Fato

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 2

Exemlos adequados: TIPO_DOCUMENTO, DESC_TIPO_DOCUMENTO

Exemplos inadequados: CODG_TIPO_DOCUMENTO, NUMR_TIPO_DOCUMENTO,

1.3.3.1 Considerações Gerais:

Para o nome dos atributos deverá ser utilizado o seguinte padrão:

Nome que define o significado da coluna.

1.3.3.3 Considerações Gerais:

3.1 Padrão de Nomes para os Objetos de Banco de Dados:

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 4

As views deverão ser descritas e documentadas no Oracle Designer.

Para o nome de Views deverá ser utilizado o seguinte padrão:

3.1.3.1 Considerações Gerais:

Views criadas a partir da tabela GEN_UNIDADE_OPERACIONAL:

GEN: Identificador do sistema

GEN: Identificador do sistema

3.1.4 Primary Key

Para o nome da Primary Key deverá ser utilizado o seguinte padrão:

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 5

3.1.4.1 Considerações Gerais:

MUNIC_PK -> Primary Key da tabela GEN_MUNICIPIO

MUNIC: ShortName da tabela;

PK: Sigla que identifica o objeto Primary Key no banco de dados;

3.1.5 Unique key

PESSOA1_UK -> Unique Key Constraint da tabela GEN_PESSOA.

3.1.6 Foreign Key

Para o nome de Foreign Key deverá ser utilizado o seguinte padrão:

É o ShortName da tabela filha

É o ShortName da tabela pai

CONTRIB_PESSOA1_FK -> FK criada entre a tabela filha CCE_CONTRIBUINTE e a pai GEN_PESSOA

CONTRIB: ShortName da tabela filha;

3.1.7 Check Constraints

Nome da coluna para a qual esta sendo criada a Check Constraint;

3.1.7.1 Considerações Gerais:

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 7

Check Constraint para a coluna TIPO_PESSOA da tabela

PESSOA: É o ShortName da tabela;

Para o nome de Sequences deverá ser utilizado o seguinte padrão:

Deverá ser informada a sigla SQ identificando que é um objeto do tipo Sequence.

3.1.8.1 Considerações Gerais:

ENDERECO_SQ -> Sequence para ser utilizado no ID da tabela GEN_ENDERECO.

Para o nome dos índices deverá ser utilizado o seguinte padrão:

Um número seqüencial para identificar o índice para a referida tabela;

Deverá ser informada a sigla IX identificando que é um objeto do tipo Índice;

3.1.9.1 Considerações Gerais:

GerenciasSTI?/GIT/SBD/BD/PadroesBdr revisão.21 − 16 Mar 2018 8