Padroes_e_Normas_para_Administracao_de_Dados

PADRÕES E NORMAS PARA ADMINISTRAÇÃO DE DADOS
Versão 1.0
Controle de Versões
Data
20/07/2011
Versão
1.0
Descrição
Criação do Documento
Autor
Diego Santos
Controle de Aprovações
Data
Versão
Descrição
Autor
Sumário
Objetivo ........................................................................................................................................ 4
Aplicabilidade .............................................................................................................................. 5
Estrutura do Documento ........................................................................................................... 5
1.
Convenção Básica para Nomenclatura .......................................................................... 6
3.
Colunas de Tabelas e Views do Banco de Dados ...................................................... 12
4.
Tipos de Dados Padrão por SGBD................................................................................ 14
5.
Normas para Modelagem de Banco de Dados ............................................................ 14
6.
Dicionário de Dados ......................................................................................................... 16
6.1.
7.
Regras Básicas ..................................................................................................... 16
Usuário ............................................................................................................................... 18
7.1.
Owner do schema ................................................................................................ 18
7.2.
Usuário da aplicação............................................................................................ 19
7.3.
Usuário de consulta.............................................................................................. 19
Objetivo
Diante deste cenário heterogêneo e considerando a complexidade existente
nos modelos de dados, a padronização e criação de normas para nomenclatura
de objetos no banco de dados é fundamental para que alcançar um alto grau
de qualidade na execução dos serviços, além de garantir a uniformidade e
manutenabilidade dos objetos a serem construídos e disponibilizados.
A padronização apresenta diversas vantagens, dentre elas:

Diminuição de custo na manutenção dos sistemas;

Coesão dos dados e sistemas e consistência nas informações fornecidas;

Eliminação de suposições, por membros das equipes, de como proceder
na criação de objetos de bancos de dados;

Facilitação do processo de manutenção dos sistemas e soluções
desenvolvidos ao longo do tempo;

Estímulo à reutilização dos objetos:
Admitir revisões e atualizações com menor impacto possível.
E permite atingir os seguintes pilares da administração de dados:

Redução ou Eliminação de Redundâncias:
Os dados deixam de ser privativos de cada sistema.

Eliminação de Inconsistências:
O dado contido em um campo sempre será o mesmo, independente de
qual sistema esteja acessando.

Restrições de Segurança:
Impede que pessoas não autorizadas utilizem ou atualizem um
determinado arquivo ou campo.

Independência dos Dados:
Os dados estariam à disposição, independente das manutenções
realizadas pela Gerência de Administração de Banco de Dados.

Manutenção da Integridade.
Aplicabilidade
Este documento se aplica a todos os objetos ligados aos bancos de dados
(tabelas, sequences, triggers, functions, procedures, packages etc.)
Não serão afetados os objetos legados, mas não será permitido que os novos
sejam criados ou recebidos fora do padrão.
Estrutura do Documento
O presente documento está organizado em 07 capítulos:
Capítulo 1 – Determina a convenção básica de nomenclatura, ou seja, a regra
macro que deverá ser seguida por todos os objetos do banco de dados.
Capítulo 2 - Apresenta uma visão geral dos possíveis objetos a serem criados
com uma breve descrição de sua utilização, a regra para formação do nome e
um exemplo.
Capítulo 3 – Determina os tipos de atributos que podem existir em tabelas e
views.
Capítulo 4 – Apresenta os tipos de dados padrão de cada SGBD.
Capítulo 5 – Descreve as principais normas para modelagem de Banco de
Dados.
Capítulo 6 – Descreve o padrão para documentação do dicionário de dados.
Capítulo 7 – Apresenta os tipos de usuários com os respectivos os privilégios
de cada uma.
1. Convenção Básica para Nomenclatura
Todos os nomes de objetos relacionados ao banco de dados devem estar:
 em letras maiúsculas,
 no singular,
 sem acentuação e
 sem caracteres especiais (tais como @, #, $, %, &, etc).
Os nomes dos objetos devem ser compostos de prefixo indicador da finalidade
do objeto e o nome propriamente dito.
O separador universal que deverá ser tanto entre prefixo e nome quanto para
nomes compostos é o caracter sublinhado ( _ ).
Evitar o uso de nomes extensos, sendo que o tamanho máximo é de 30
caracteres.
Caso o nome do objeto exceda o limite de 30 caracteres, poderão ser usados
acrônimos ou abreviações.
O uso de acrônimo deve seguir a convenção nacional, por exemplo: CEP, CPF,
PETI.
O uso de abreviações deve seguir as regra geral de abreviaturas:
 A abreviatura deve ter metade ou menos da metade da palavra original, do
contrário,
será
melhor
escrever
a
palavra
por
extenso.
 A regra geral para abreviatura das palavras é simples. Basta escrever a
primeira sílaba e a primeira letra da segunda sílaba. Ex.: fut. (futuro), adj.
(adjetivo), gram. (gramática).
 Nunca corte a palavra numa vogal, sempre numa consoante.
 As palavras abreviadas não devem ter comprimento menor que 3(três)
caracteres, a não ser que seja auto-explicativa (kg, gb, mb).
 Caso a primeira letra da segunda sílaba seja vogal, escreve-se até a
consoante.
 Se a segunda sílaba iniciar por duas consoantes, as duas farão parte da
abreviatura. Ex.: pess. (pessoa), secr (secretário).
2. Objetos de Banco de Dados
Objeto
Schema
Descrição
Padrão de Nomenclatura
Um conjunto de objetos de
propriedade de um usuário
(OWNER).
O nome do schema
normalmente representa o
sistema
Tabela utilizada para
armazenar dados.
TB_+[NOME DA TABELA]
Exemplo
CERIMONIAL
CADUNICO
(Tabela de Sistema)
Existem diversos tipos de
tabelas que serão detalhadas TR_+[NOME DA TABELA1]
+_+[NOME DA TABELA2]
no próximo capítulo.
(Tabela de Relacionamento)
TH_+[NOME DA TABELA]
TB_ENTIDADE
(Tabela de Histórico)
TB_CRIANCA_PETI
TMP_+[NOME DA TABELA]
TR_USUARIO_PERFIL
(Tabela Temporária)
TH_PAGAMENTO
Table
BCK+[NOME DA TABELA]
(Backup de Tabela )
Obs.: as tabelas TMP e BCK
são de uso interno do banco de
dados e devem ficar em um
schema separado no banco.
View
É uma representação lógica
de uma ou de várias tabelas
VW_+[NOME DA VIEW]
armazenadas em banco, mas
sem armazenamento próprio.
VW_CRAS
VW_PLANO_2009
O comentário da VW deverá
ser feito como o de uma
tabela.
Materialized
View
ou
É uma representação lógica
de uma ou de várias tabelas
armazenadas em banco, mas MV_+[NOME DA VIEW]
com armazenamento próprio.
MV_STATUS_PLANO
Snapshots
Sequence
Constraint
Check
Objeto do banco utilizado
SQ_+[NOME DA TABELA]
para gerar números inteiros
únicos. Normalmente utilizado Obs1: O nome da tabela deve
perder o prefixo TB.
para gerar códigos que
servirão como primary key.
Define restrições de
preenchimento para a coluna.
O processamento é realizado
pelo banco de dados sobre
valores informados.
SQ_ENTIDADE
SQ_ENDERECO
CK_+[NOME DA
TABELA]+_+[NOME DA
COLUNA]
Obs:
CK_ENTIDADE_STATIV
O
Os nomes da tabela e da
coluna devem perder os
prefixos.
O caracter ‘_’ deve ser
suprimido quando existir.
Determina uma coluna ou um
conjunto de colunas que
possuem valores em outras
tabelas. Relativa a uma
referência ou a um
relacionamento.
Foreign Key
FK_+[NOME DA TABELA
PAI]+_+ [NOME DA TABELA
FILHO]
Onde:
NOME DA TABELA PAI –
tabela que é referenciada, que
contém a PK;
NOME DA TABELA FILHO –
tabela que referência, que
contém a FK;
Obs:
O nome da tabela deve perder
o prefixo TB.
O caracter ‘_’ deve ser
suprimido do nome da tabela
quando existir.
FK_UF_MUNICIPIO
FK_TIPOENTIDADE_EN
TIDADE
Índice utilizado para identificar Índice utilizado para identificar
univocamente cada linha da
univocamente cada linha da
tabela.
tabela.PK_+[NOME DA
TABELA]
Obs:
PK_MUNICIPIO
PK_ENTIDADE
Primary Key
O nome da tabela deve perder
o prefixo TB.
O caracter ‘_’ deve ser
suprimido do nome da tabela
quando existir.
Índice que não é o primário,
mas que evita a duplicidade
de registro, isto é, esta
constraint determina que uma
coluna não poderá ter duas
linhas com o mesmo valor.
1-Formação simples
UK_+[NOME DA
TABELA]+_+[NOME DA
COLUNA]
2-Formação com mais de um
atributo na UK
UK_+[NOME DA
TABELA]+_+[NOME DA
COLUNA] +_+[NOME DA
COLUNA]
Unique Key
UK_BENEFICIARIO_NIS
UK_SERVIDOR_CPF
Obs:
Os nomes da tabela e da
coluna devem perder os
prefixos.
O caracter ‘_’ deve ser
suprimido do nome da tabela e
da coluna quando existir.
Objeto de um esquema que
pode otimizar a recuperação
de linhas.
Index
1-Formação simples
IX_+[NOME DA
TABELA]+_+[NOME DA
COLUNA]
2-Formação com mais de um
atributo na formação do
índice
IX_+[NOME DA
TABELA]+_+[SEQUENCIAL
COM 3 DÍGITOS]
Obs:
Os nomes da tabela e da
coluna devem perder os
IX_USUARIO_NUCPF
IX_ENTIDADE_001
prefixos.
O caracter ‘_’ deve ser
suprimido do nome da tabela e
da coluna quando existir.
Armazena o rowid com o valor IB_+[NOME DA
da chave.
TABELA]+_+[NOME DA
COLUNA]
Obs:
Bitmap Index
IB_USUARIO_NUCPF
O nome da tabela e o nome da
coluna devem perder o prefixo
e os caracteres ‘_’ devem ser
suprimidos.
Table Partition
Partition Index
Consiste em partições
(tabelas menores) para cada
grupo de valor de entrada
indexado em colunas de uma
tabela. Por exemplo,
particionar beneficiários por
UF.
PD+_+[NOME DA TABELA]
+_+[NOME DA
COLUNA]+_+[RANGE]
Obs:
PD_BENEFICIARIO_UF
_AC
O nome da tabela e o nome da
coluna perdem o prefixo e o
caracter ‘_’.
Consiste em partições para PI+_+[NOME DA TABELA]
cada valor de entrada
+_+[NOME DA COLUNA]
indexado em colunas de uma +_+[RANGE]
tabela.
Obs:
PI_BENEFICIARIO_UF_
AC
O nome da tabela e o nome da
coluna perdem o prefixo e o
caracter ‘_’.
Database Link
Nomenclatura para links entre DBL+_+[BANCO]
schemas/bancos para os
+_+[USUARIO]
usuários externos a este
O nome do usuário perde o
schema/banco
caracter ‘_’.
Function
São
rotinas
de FC_+[NOME DA FUNÇÃO]
processamento que retornam O nome da função deve indicar
valores.
o objetivo da mesma.
FC_CALCULA_DV
Stored
Procedure
PR_+[NOME DA
Conjunto de procedimentos PROCEDURE]
armazenados no banco.
O nome da procedure deve
indicar o objetivo da mesma.
PR_IMPORTA_ARQUIV
O
Package
Grupo
funções,
PC_ACERTO_DADOS_
de
procedures, PC_+[NOME DO PACKAGE]
comandos sql e
DBL_GEOBD_SCOTT
variáveis,
diretamente
dados.
que
executa O nome da procedure deve
no banco de indicar o objetivo da mesma.
Agrupamento de comandos
PL/SQL e especificações
Utilizar o mesmo nome da
Package Body disponíveis para todos os
Package
objetos públicos listados na
Package.
METAS
PC_ACERTO_DADOS_
METAS
TG_+[AÇÃO] +_+[NOME DA
TABELA]
TGA_+[NOME DA TABELA]
(Trigger de Auditoria)
Obs:
Trigger
(Row /
Statement)
Procedimento a ser disparado
O nome da tabela deve perder
antes ou após a exclusão de
o prefixo TB.
um
registro
da
tabela
associada.
O caracter ‘_’ deve ser
suprimido do nome da tabela e
da coluna quando existir.
TG_ATUALIZASTATUS_
ENTIDADE
TG_DELETAHISTORIC
O_BENEFICIARIO
TGA_ENTIDADE
TG_ATUALIZASTATUS_
ENTIDADE_001
Caso exista Trigger com o
mesmo nome deverá ser
incluído +’_’+ [SEQUENCIAL
COM 3 DÍGITOS]
TS_+[NOME DO
SCHEMA]_DAT+[N°SEQUENC
IALCOM 3 DÍGITOS]
Tablespace
Genérico
de
Dados
ou
Obs. O número sequencial só
TS_CADUNICO_DAT_0
deve ser usado quando q
01
quantidade de tablespaces de
dados do schema for maior que
1.
TS_+[NOME DO
SCHEMA]_IDX+[N°SEQUENCI
ALCOM 3 DÍGITOS]
Tablespace
Tablespace de Índices
Tablespace de Lob
TS_CERIMONIAL_DAT
Obs. O número sequencial só
deve ser usado quando q
quantidade de tablespaces de
índices do schema for maior
que 1.
TS_ CERIMONIAL _IDX
TS_CADUNICO_IDX_00
1
TS_+[NOME DO
TS_ CERIMONIAL _LOB
SCHEMA]_LOB+[N°SEQUENC
TS_CADUNICO_LOB_0
IALCOM 3 DÍGITOS]
01
Obs. O número sequencial só
deve ser usado quando q
quantidade de tablespaces de
lobs do schema for maior que
1.
3. Colunas de Tabelas e Views do Banco de Dados
Tipos de Colunas das
Tabelas e Views
Padrão de
Nomenclatura
Data Type
Padrão
Código numérico,
seqüencial e único que
representa a chave
primária, identificador da
tabela.
ID_+[NOME DO
ATRIBUTO]
Numérico
Código numérico que
representa a chave
primária, identificador da
tabela. A unicidade neste
campo não é obrigatória.
(não necessariamente
seqüencial)
CD_+[NOME DO
ATRIBUTO]
Numérico
Número
NU_+[NOME DO
ATRIBUTO]
Texto
DT_+[NOME DO
ATRIBUTO]
Data
Referência
RF_+[NOME DO
ATRIBUTO]
Texto
Hora
HR_+[NOME DO
ATRIBUTO]
Hora
DS_+[NOME DO
ATRIBUTO]
Texto
NM_+[NOME DO
ATRIBUTO]
Texto
VL_+[NOME DO
ATRIBUTO]
Valor
Data
Descrição
Nome
Valor
Exemplo
ID_PESSOA
ID_DOMICILIO
CD_PRODUTO
CD_DOMICILIO
NU_CPF
NU_ANO_BASE
DT_VENDA
DT_INICIO_ATIVIDADE
RF_FOLHA
HR_CHEGADA
HR_EMISSAO_TITULO
DS_OBSERVACAO
DS_ENDERECO_LOJA
NM_UF
NM_PESSOA
VL_PAGAMENTO
VL_SALARIO_BRUTO
Sigla
Quantidade
SG_UF
SG_+[NOME DO
ATRIBUTO]
Texto
QT_+[NOME DO
ATRIBUTO]
Valor
ST_+[NOME DO
ATRIBUTO]
Caractere
SG_PREFIXO_DOC
QT_PESSOA_DOMICILIO
QT_INTEGRANTE_FAMILIA
Status
O Status representa um
campo que só permite 2
valores, geralmente Sim
ou Não.
ST_ATIVO
Domínio: S ou N
IN_ESTADO_CIVIL
Domínio:
Indicador
O indicador representa um IN_+[NOME DO
campo que possui um
ATRIBUTO]
conjunto de domínio maior
que 2 elementos.
S (Solteiro)
Caractere
C (Casado)
E (Separado)
D (Divorciado)
V(Viúvo)
Tipo
Tipo é um campo que
obrigatoriamente são
TP_+[NOME DO
referenciados pelas
ATRIBUTO]
tabelas DOMINIO_TIPO e
TIPO, explicadas no Item 7
do Capítulo 5
Número
TP_DOCUMENTO
4. Tipos de Dados Padrão por SGBD
Tipo de Dados
Oracle
SQL Server
DB2
PostgreSql
My Sql
Integer
Integer
Numeric(n)
Smallint
Integer
Numérico
Number(n)
Decimal(n)
Smallint
Smallint
Texto
Varchar2(n)
Date
Varchar(n)
Date
Varchar(n)
Character
varying(n)
Varchar(n)
Date
Date
Date
timestamp
Timestamp
Timestamp
Timestamp
Time
Time
Data
Timestamp
Hora
Timestamp
Valor
Number(n,m)
Datetime
Integer
Caractere
Char(1)
Decimal(n,m)
Numeric(n,m)
Decimal(n,m)
Decimal(n,m)
Char(1)
Character(1)
Character (1)
Char(1)
5. Normas para Modelagem de Banco de Dados
1. Nenhum atributo deve ser armazenado com máscaras, exemplo: CEP,
CPF, CNPJ e etc.
2. Nenhum atributo deve ser armazenado com formatação, como por exemplo
tags html.
3. Os dados que representam informações compostas por números (números
de documentos, números de processos, números de endereço, etc..) devem
ser armazenados com o tipo de dados caractere (varchar), sem guardar
mascaras para estes números. Isso é necessário considerando a existência
de “zeros a esquerda” que podem ser significativos para estes números. Por
exemplo, a informação de um CPF 00275478942, se guardada como
numero no banco de dados irá ter os zeros excluídos.
4. Quanto uma tabela possuir Chave primária composta além de outros
atributos, e esta tabela estiver envolvida em relacionamentos com outras
tabelas do banco de dados, para evitar a transposição de chaves
estrangeiras compostas, deve ser criado um índice único para os atributos
da chave primária verdadeira, de forma a garantir a integridade real dos
dados, e adicionado um novo atributo do tipo “ID” para a tabela, que será a
chave primária “falsa” gerada seqüencialmente.
5. Deve-se evitar o uso de sinônimos. O acesso do sistema (SCHEMA) deverá
ser preferencialmente referenciado. Esta norma evita de que um schema
tenha duplicidade em sinônimos por acessar tabelas de mesmo nome em
schema diferentes.
6. Todos os objetos temporários devem ser criados em schemas temporários,
nunca nos schemas reais. As rotinas de auditoria realizadas mensalmente
nos schemas irá dropar os objetos que não fizerem parte do schema.
7. As procedures e functions devem possuir um cabeçalho com as seguintes
informações:
 Nome da Procedure/Function:
 Objetivo:
 Parâmetros de Entrada:
 Pré-Condições:
 Autor:
 Data Criação
 Data Modificação:
 Motivo Modificação:
6. Dicionário de Dados
Entendemos por dicionarização o “Registro detalhado dos conceitos que
compõem um universo pré-definido”. Os seus objetivos principais são:
 Registrar e padronizar conceitos;
 Aumentar a fidelidade ao negócio na interpretação dos conceitos.
6.1.Regras Básicas
No momento de escrevermos uma descrição é importante entender que “A
representação gráfica e denominação dos elementos que compõem um modelo
de dados não são suficientes para traduzir todos os conceitos do negócio”.
Portanto deve-se levar em consideração os seguintes itens:
1) Fatores que devem ser considerados na descrição:
 Clareza;
 Objetividade;
 Respeito à terminologia da área negocial que está sendo tratado;
 Respeito às normas da língua portuguesa;
 Citação de exemplos.
2) Fatores que devem ser evitados na descrição:
 Ambigüidade;
 Sintetização exagerada;
 Distorção do sentido dos termos.
3) Fatores para melhor compreensão do modelo de dados, visando a aumentar
o grau de fidelidade na interpretação dos mesmos:
 Nenhum modelo é suficientemente claro se não for acompanhado de
uma definição formal dos elementos;
 Descrições que possam parecer triviais a quem está modelando não
serão do mesmo modo triviais a outras pessoas que não tenham o
conhecimento prévio do assunto tratado.
 Assumir que um conceito é trivial e não precisa ser detalhado é assumir
os riscos de futuras interpretações equivocadas.
 O
estabelecimento
de
definições
completas
e
inequívocas
é
extremamente importante, portanto devemos buscar durante essa
definição meios para sermos precisos, claros e específicos.
4) Fatores que devem ser considerados para UMA BOA DESCRIÇÃO:
 Regras nas quais os elementos conceituados se encaixam;
 Exceções às regras, quando aplicáveis;
 Exemplos ilustrativos;
 Correlação entre conceitos descritos;
 Acréscimo de qualquer outro tipo de informação que contribua para a
compreensão.
5) Perguntas que devem ser respondidas sobre a entidade:
 O que é a entidade?
 O que faz a entidade?
 Para que serve?
 O que engloba a categoria de elementos que compõem a entidade?
 O que está excluído dessa categoria?
 Quando alguém ou algo passa a ser, ou deixa de ser, um elemento
dessa entidade?
 Sua permanência nessa categoria é imutável?
É importante observar que ao responder essas perguntas estamos procurando
conceituar a entidade, pois na descrição deve-se ficar claro o que é a entidade
representada na tabela e não que esta tem como finalidade armazenar os
dados da entidade.
O conjunto mínimo de informações que um dicionário de dados deve conter,
considerando os itens acima, é:
 Descrição de todas as entidades: as entidades devem ter seu significado
descrito, com informações sobre quais dados serão armazenados na
mesma;
 Tabelas: considerando que este é o objeto mais significativo do banco de
dados devemos documentá-lo com bastante atenção, a sua descrição deve
conter o conceito da entidade por ela representada, incluindo a importância e
a relação com outras tabelas e objetos do banco.
 Sequences: deve conter a descrição e a regra de incremento;
 Chaves e Índices: devem estar descritos relacionando os atributos que
compõem estes objetos;
 Descrição dos atributos: os atributos devem ser detalhados, os dados que
os mesmos irão armazenar devem ser descritos, correlações entre atributos
que envolvam regras de negócios devem ser relatados; opção por tipos de
dados específicos devem ser documentadas;
 Relacionamentos: Os relacionamentos devem estar documentados quanto
a sua cardinalidade e obrigatoriedade, explicando questões sensíveis a
regra de negócios definida;
 Visões: as mesmas devem estar descritas, principalmente no que diz
respeito a sua usabilidade;
 Gatilhos (Triggers): Devem estar descritas, suas ações devem ser
explicadas e também a sua correlação com a implementação de regras de
negócios devem ser descritas;
 Procedimentos armazenados(Stored Procedure): os procedimentos
armazenados devem ser descritos quanto a sua funcionalidade;
7. Usuário
Cada schema de banco de dados deverá ter no mínimo 2 usuários:
 owner de schema
 usuário de aplicação.
7.1.Owner do schema
Este usuário tem privilégios totais no schema, por isso deve ser de
conhecimento apenas da equipe de Banco de Dados (Administradores de
Dados e Administradores de Banco de Dados)
O nome deste usuário é formado pelo <<nome do objeto>>. Ex.: CERIMONIAL
7.2. Usuário da aplicação
O usuário da aplicação deverá ter privilégios apenas de execute nas funções,
select nas tabelas, sequences e views e insert, update, delete das tabelas.
Apenas nos casos em que for necessário deverão ser criados sinônimos para
acesso das tabelas, sequences e views.
O nome do usuário da aplicação é o formado pelo <<nome do objeto>> +_
USU. Exemplo: CERIMONIAL_USU
7.3.Usuário de consulta
Caso seja necessário que algum departamento execute consultas diretamente
na base de dados, deverá ser disponibilizado um usuário específico para isso.
Esse usuário só terá privilégios de select nos objetos (tabelas ou views)
necessárias.
Este usuário não deve ter sinônimos para os schemas de banco de dados, o
acesso aos schemas deve ser referenciado.
As finalidades, padrões de nomenclatura e forma de acesso são descritos a
seguir:
SCHEMA
FINALIDADE
USUÁRIO
(Exemplo)
[SCHEMA]
Onwer do schema. Deve ter privilégio
de DBA no schema
CERIMONIAL
[SCHEMA]_+USU
Usuário para operação da aplicação.
Tem privilégio de INSERT, SELECT,
UPDATE E DELETE nas tabelas,
SELECT nas views e sequences e
EXECUTE nas procedures e functions.
CERIMONIAL_USU
[SCHEMA]_+CONS
Usuário com direito só para consulta.
Tem privilégio apenas de SELECT em
tabelas e views.
CERIMONIAL_CONS