Guia para criação de Bancos de dados, esquemas, tabelas e demais objetos de

dados.
1. Objetivo
Este guia de desenvolvimento tem o objetivo de apresentar aos desenvolvedores da JIVE as diretrizes para criação dos objetos (bancos,
esquemas, tabelas, índices e demais) nos bancos de dados que compõe a base da dados do Sistema Interno de Gestão, conhecido pelo
codinome “INDIE“.

As equipes de Data Engeneering, Business Intelligence & Analytics (DB&A) e Arquitetura estão alinhadas com os padrões e apoiarão as
orientações estabelecidas neste Guia.

Situação não previstas neste documento deverão ser previamente analisadas e adicionadas a este de forma a garantir o padrão.

2. Padrões para criação de bases de dados

Este capítulo tem por objetivo detalhar os padrões de nomenclatura para criação de novos bancos de dados.

Importante: Os exemplos utilizados neste capítulo são meramente ilustrativos.

2.1. Nomenclatura de bases de dados

Todas devem sem iniciadas pelo prefixo sig_;
Não devem conter verbo em seu nome;

Devem estar em inglês e no singular;

Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;

Não devem ser usados nem acentuação e nem caracteres especiais;

Evitar o uso de números;
O tamanho do nome não deve ultrapassar 50 (cinquenta) caracteres;
Caso ocorra, abrevie os complementos menos relevantes, de forma que seja possível seu entendimento no momento da leitura;

Deve ter um nome coerente com o seu objetivo, que não deixe dúvidas a que se destina;
Não devem ser utilizadas preposições;
Não devem conter nomes próprios, de assuntos específicos ou qualquer nome que restrinja sua utilidade;

Exemplos:

sig_main_db;
sig_load_db.

3. Padrões para criação de esquemas

Este capítulo tem como objetivo detalhar os padrões de nomenclatura para criação de novos esquemas em cada um dos bancos de
dados.

Importante: Os exemplos utilizados neste capítulo são meramente ilustrativos.

3.1. Nomenclatura de esquemas

Deverão ser adotados os seguintes critérios para nomeação de esquemas:

Não devem conter verbo em seu nome;

Devem estar em inglês e no singular;
 Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;
Não devem ser usados nem acentuação e nem caracteres especiais;
Evitar o uso de números;

O tamanho do nome não deve ultrapassar 50 (cinquenta) caracteres;

Caso ocorra, abrevie os complementos menos relevantes, de forma que seja possível seu entendimento no momento da leitura;

Deve ter um nome coerente com o seu objetivo, que não deixe dúvidas a que se destina;
Não devem ser utilizadas preposições;
Não devem conter nomes próprios, de assuntos específicos ou qualquer nome que restrinja sua utilidade.

Sugere-se que o nome faça referencia ao serviço ao qual as tabelas a serem criadas no mesmo pertençam.

Exemplos:

system;
core;
investment.

4. Padrões para criação de tabelas e derivados

Este capítulo tem como objetivo detalhar os padrões de nomenclatura para criação de novas tabelas e seus derivados:

Campos.

Índices;
Tabelas auxiliares e/ou de domínio ;

Importante: Os exemplos utilizados neste capítulo são meramente ilustrativos.

4.1. Nomenclatura de tabelas

Deverão ser adotados os seguintes critérios para nomeação de tabelas:

Todas devem sem iniciadas pelo prefixo tbl_;

Não devem conter verbo em seu nome;

Devem estar em inglês e no singular;

Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;

Não devem ser usados nem acentuação e nem caracteres especiais;

Evitar o uso de números;
O tamanho do nome não deve ultrapassar 50 (cinquenta) caracteres;

Caso ocorra, abrevie os complementos menos relevantes, de forma que seja possível seu entendimento no momento da leitura;
Deve ter um nome coerente com o seu objetivo, que não deixe dúvidas a que se destina;
Não devem ser utilizadas preposições;
Não devem conter nomes próprios, de assuntos específicos ou qualquer nome que restrinja sua utilidade.
As tabelas filho devem referenciar

Exemplos:

tbl_group;

tbl_user;
tbl_user_group.
4.2. Nomenclatura de Campos

Deverão ser adotados os seguintes critérios para nomeação de campos:

Não devem conter verbo em seu nome;

Devem estar em inglês e no singular;
Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;

Não devem ser usados nem acentuação e nem caracteres especiais;

Evitar o uso de números;
O tamanho do nome não deve ultrapassar 50 (cinquenta) caracteres;

Caso ocorra, abrevie os complementos menos relevantes, de forma que seja possível seu entendimento no momento da leitura;
Deve ter um nome coerente com o seu objetivo, que não deixe dúvidas a que se destina;

Não devem ser utilizadas preposições;

Não devem conter nomes próprios, de assuntos específicos ou qualquer nome que restrinja sua utilidade.
Deverão seguir prefixo e tipagem alinhados conforme tabela abaixo.

Mnemônico Natureza Tipagem indicada

id Identificador (único) smallint, int, bigint, int4, int8, int16, smallserial, serial, bigserial, oid, uuid

cd Código char, varchar

ds Descrição varchar, nvarchar, varchar2

dt Data date, time, datetime, timestamp

qt Quantidade smallint, int, bigint, int4, int8, int16

nr Número numeric, decimal

pc Percentual numeric, decimal

vl Valor numeric, decimal, money, currency

fg Flag / Binário boolean, bit

tx Texto longo varchar(max), nvarchar(max), varchar2(max), blob

js JSON json, jsonb

4.2.1. Campos obrigatórios

Por convenção, toda tabela criada deverá, obrigatoriamente, conter os seguintes campos conforme lista disponibilizada:

Chave primária:

id_pramary_key SMALLSERIAL / SERIAL / BIGSERIAL

Flag para inativar o registro:
fg_inactive BIT

Data de criação do registro:

dt_create DATETIME
Data com a última atualização do registro:
dt_update DATETIME
Id do usuário responsável pela inclusão do registro:
id_user_create INT
 Id do usuário responsável pela inclusão do registro:
id_user_update INT

4.2.2. Chaves primárias

Conforme dito no item 4.2.1. deste, toda tabela criada deverá obrigatoriamente conter uma chave primária (constraint primary key), mesmo
as que sejam apenas uma “tabela ponte“ ou uma tabela de informações complementares. O nome da chave primária deverá ser composta
da seguinte maneira:

4.2.2.1. Campo

Prefixo: id

Sufixo: o mesmo utilizado na nomeação da tabela:

Exemplos:

tbl_group → id_group;
tbl_user → id_user;
tbl_user_group → id_user_group (bridge table);

4.2.2.2. Arquivo de chave

Prefixo: cpk;

Sufixo: o mesmo utilizado na nomeação da tabela.

Exemplos:

tbl_group → cpk_group
tbl_user → cpk_user
tbl_user_group → cpk_user_group (bridge table)

4.2.2. Nomenclatura de chaves estrangeiras

Na necessidade de chaves estrangeiras (constraint foreign key), estas deverão ser compotas da seguinte maneira:

Prefixo: cfk;

Sufixo: o mesmo utilizado na nomeação da tabela;

Complemento: o nome do campo ao qual a chave referencia.

Exemplos:

tbl_group
PK: id_group;
tbl_user
PK: id_user;
tbl_user_group (bridge table):

PK: id_user_group
FK: id_group → cfk_user_group_group
FK: id_user → cfk_user_group_user

Importante: todo campo que represente uma chave estrangeira deverá seguir exatamente a mesma nomenclatura utilizada na tabela pai.
Entende-se como exceção situações onde a mesma tabela pai será referenciada mais que uma vez. Neste caso, todas as ocorrências
deverão receber uma nomenclatura complementar que os diferencie:

Exemplos:

tbl_user: (padrão)
 PK: id_user;
tbl_company: (exceções previstas)

FK: id_user_insert;
FK: id_user_update.

4.2.3. Nomenclatura de chaves checagem de valores/conteúdo

Na necessidade criação de limitações de preenchimento dos campos (constraint check value), estes deverão ser compotas da seguinte
maneira:

Prefixo: ccv;

Sufixo: o mesmo utilizado na nomeação da tabela;

Complemento: o nome do campo ao qual a chave referencia.

Exemplos:

tbl_user:
ds_eletronic_mail → ccv_user_eletronic_mail ;

4.3. Nomenclatura de índices

Deverão ser adotados os seguintes critérios para nomeação de índices:

Todos devem sem iniciadas pelo prefixo idx_;

Não devem conter verbo em seu nome;
Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;

Não devem ser usados nem acentuação e nem caracteres especiais;

Devem referenciar a tabela a qual pertencem;
Devem ser utilizados números, de forma sequencial em relação a sua criação, com o objetivo de simplificar a nomeação e evitar nomes
longos (que ultrapassem 50 caracteres);

Exemplos:

tbl_user:
idx_user_01

tbl_company:
idx_company_01
idx_company_02

4.4. Nomenclatura de tabelas auxiliares e/ou de domínio

Deverão ser adotados os seguintes critérios para nomeação de tabelas auxiliares:

Todas devem sem iniciadas pelo prefixo aux_;

Não devem conter verbo em seu nome;
Devem estar em inglês e no singular;
Devem ser escritas com letras minúsculas, separando as palavras “_” (underline)
snake_case;
Não devem ser usados nem acentuação e nem caracteres especiais;
Evitar o uso de números;
O tamanho do nome não deve ultrapassar 50 (cinquenta) caracteres;
Caso ocorra, abrevie os complementos menos relevantes, de forma que seja possível seu entendimento no momento da leitura;
 Deve ter um nome coerente com o seu objetivo, que não deixe dúvidas a que se destina;
Não devem ser utilizadas preposições;

Não devem conter nomes próprios, de assuntos específicos ou qualquer nome que restrinja sua utilidade.
As tabelas filho devem referenciar

Exemplos:

aux_postal_code;
aux_status_user;
aux_status_investments.

4.5. Nomeação de tabelas especiais, “historificação” de valores

Serão consideradas tabelas especiais, tabelas que forem elaborada para acumular a sequencia e data de eventos específicos, como por
exemplo, o histórico de estados de de um documento, cujo as variações possam gerar informação

Para estes caso deverão ser adotados os seguintes critérios para nomeação destas tabelas especias:

Devem obrigatoriamente ter como sufixo o nome da tabela que a origina;

Devem indicar a informação que está sendo “historificada”;
Devem seguir todas as demais característica indicadas para uma tabela padrão;
Devem ser associadas a uma tabela auxiliar de domínio;

Exemplos:

tbl_investment;
tabela principal;
tbl_investment_status;
tabela que contem a “historificação” do campo id_status_investment;
aux_status_investments;
tabela auxiliar com o domínio do campo id_status_investment.

4.5.1. Tabelas longas e colunas de texto longo

Entende-se por tabelas longas, tabelas que contenham uma quantidade de colunas superior a 20.

Entende-se por coluna de texto longo as que possuam uma largura superior a 4000 bytes.

Para estes casos especiais, recomenda-se que a tabela seja dividida em duas parte, mantendo os campos com baixa volatilidade ou sem
necessidade de atualizações na tabela principal e os campos de alta volatilidade em uma tabela complementar. Esta medida evitará a
fragmentação excessiva da base de dados e consequente lentidão no servido, reduzindo também a necessidade de manutenções.

Exemplos:

tbl_investment;
tabela principal com campos de baixa volatilidade;
tbl_investment_complement;
tabela complementar com campos de alta volatilidade;
tbl_investment_text;
tabela complementar com campos de texto longo;
5. Procedures & Funções
Este capítulo tem como objetivo detalhar os padrões de nomenclatura para criação de novas procedures e funções definidas pelos
usuários.

Importante: Os exemplos utilizados neste capítulo são meramente ilustrativos.

5.1. Procedures

Para nomear uma procedure é necessário seguir as regras de nomenclaturas:

5.1.1. C.R.U.D

Para nomear uma procedure é necessário seguir as regras de nomenclaturas:

5.1.2. de seleção de dados

Para nomear uma procedure é necessário seguir as regras de nomenclaturas:

5.1.3. Avulsas

Para nomear uma procedure é necessário seguir as regras de nomenclaturas:

5.2. Funções

Para nomear uma procedure é necessário seguir as regras de nomenclaturas:

6. Anexos

6.1. Glossário de termos, siglas e abreviaturas

Bases de dados: banco de dados (database);

DB&A: Data, Business Intelligence & Analytics. Área da Jive responsável pela ingestão, armazenamento, manipulação e distribuição
interna de dados e informações;
Esquemas:
Índices:
Sequências:
Snake case: forma de notação em programação e/ou criação de objetos.
Exemplos de outras formas de notação:
UPPERCASE;
lowercase;
CamelCase;
snake_case.
Tabelas: