1 - Sefaz-BA

SEFAZ-BA
SGF
DTI
GEDES
Secretaria da Fazenda do Estado da Bahia
Superintendência da Gestão Fazendária
Diretoria de Tecnologia da Informação
Gerência de Administração de Dados e Desenvolvimento de Sistemas
MANUAL DE PADRÕES
BANCO
Versão 01.28.00
Salvador (Ba), maio de 2017
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
CONTROLE DE VERSÃO
Versão
Data
Responsável
Histórico
01.24.00 15/02/2013
Equipe AD
(Padrões)
1. Alteração no item LEGENDA E
CABEÇALHO
01.25.00 16/12/2013
Equipe AD
(Padrões)
1. Alteração no item LEGENDA E
CABEÇALHO
01.26.00 22/10/2014
Equipe AD
(Padrões)
Alterações nos seguinte itens:
1. CONSIDERAÇÕES GERAIS
2. NOMES LÓGICOS DOS SERVIDORES
01.27.00 20/05/2015
Equipe AD
(Padrões)
Alterações nos seguinte itens:
1. NOMES LÓGICOS DOS
SERVIDORES
2. NOMENCLATURA DE
OBJETOS DE BANCO DE
DADOS
01.28.00 20/11/2015
Equipe AD
(Padrões)
Alteração no item:
CONSIDERAÇÕES GERAIS
Página 2
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
RESUMO
O presente documento contempla os Padrões de Banco de Dados adotados na Secretaria da
Fazenda do Estado da Bahia. Esse Manual abrange desde a nomenclatura para criação de
usuários até os objetos gerenciados ou não pela Ferramenta Case adotada.
Esse Manual não contempla recomendações sobre quando, como e/ou onde usar ou não
determinadas funcionalidades providas pelo SQL Server. Quando for necessário buscar
informações desse tipo, deve-se ler o documento Boas Práticas de Programação - TransactSQL.doc.
Por fim, os procedimentos em relação à criação dos objetos no Banco de Dados estão
descritos no Manual de Procedimentos Gerais de Sistemas.
Página 3
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
ÍNDICE
1.
ACESSO (LOGINS, GRUPOS E USUÁRIOS) ................................................................5
1.1.
LOGINS .................................................................................................................................. 5
1.1.1.
GRUPOS E USUÁRIOS ................................................................................................ 5
2.
NOMENCLATURA DE OBJETOS ..................................................................................6
2.1.
CONSIDERAÇÕES GERAIS ................................................................................................ 6
2.2.
NOMENCLATURA DE OBJETOS DE BANCO DE DADOS .............................................. 7
2.2.1.
BANCO DE DADOS ..................................................................................................... 7
2.2.2.
STORED PROCEDURES ............................................................................................. 8
2.2.3.
USER FUNCTIONS ...................................................................................................... 9
2.2.4.
TRIGGERS .................................................................................................................... 9
2.2.5.
VIEWS ......................................................................................................................... 10
2.2.5.1.
2.2.5.2.
2.2.5.3.
2.2.5.4.
2.2.5.5.
2.2.6.
2.2.7.
2.2.8.
2.2.9.
2.2.10.
2.2.11.
2.2.11.1.
2.2.11.2.
2.2.12.
2.2.13.
2.2.14.
2.2.15.
2.2.16.
2.2.17.
2.2.18.
2.2.19.
2.2.20.
2.2.20.1.
2.2.20.2.
2.2.21.
2.2.21.1.
2.2.21.2.
2.2.21.3.
2.2.21.4.
2.2.21.5.
2.2.21.6.
3.
PACOTES DTS DO DW ............................................................................................. 12
CUBOS DO DW .......................................................................................................... 14
DATA SOURCE NAME (DSN) .................................................................................. 15
ESTATÍSTICAS DE BANCO ..................................................................................... 15
SERVIDOR .................................................................................................................. 15
INSTÂNCIAS .............................................................................................................. 16
INSTÂNCIA PADRÃO ......................................................................................................... 16
INSTÂNCIA NOMEADA ..................................................................................................... 16
SCHEMAS ................................................................................................................... 17
SINÔNIMOS ................................................................................................................ 17
LINKED SERVER ....................................................................................................... 17
NOMES LÓGICOS DOS SERVIDORES ................................................................... 18
INSTÂNCIAS POR NOME LÓGICO DOS SERVIDORES ...................................... 18
JOBS ............................................................................................................................ 19
FILAS ........................................................................................................................... 20
ENTIDADE .................................................................................................................. 20
ATRIBUTO.................................................................................................................. 23
ATRIBUTO FONETIZADO ................................................................................................. 24
TIPO DE DADOS .................................................................................................................. 25
CONSTRAINTS .......................................................................................................... 28
CHAVE PRIMÁRIA ............................................................................................................. 28
ÍNDICE SECUNDÁRIO........................................................................................................ 28
ÍNDICE PARA TESTES DE PERFORMANCE ................................................................... 29
CHAVE ESTRANGEIRA ..................................................................................................... 29
CHECK .................................................................................................................................. 30
DEFAULT ............................................................................................................................. 31
INDEPENDÊNCIA DE CODIFICAÇÃO .......................................................................32
3.1.
3.2.
4.
VIEWS COMUNS ................................................................................................................. 10
VIEWS DE REPLICAÇÃO ................................................................................................... 11
VIEWS DE LINKED SERVER ............................................................................................. 11
VIEWS INDEXADAS ........................................................................................................... 11
VIEWS DO DW..................................................................................................................... 12
USO DE COMANDOS “SELECT *” E “INSERT *” ........................................................... 32
REFERENCIAR ENTIDADES E ATRIBUTOS .................................................................. 32
PADRÃO DE LAYOUT DE TRIGGERS .......................................................................32
4.1.
4.2.
4.3.
4.4.
4.5.
CONSIDERAÇÕES GERAIS .............................................................................................. 32
TRIGGERS SEM CURSOR ................................................................................................. 33
TRIGGERS COM CURSOR ................................................................................................ 35
TRIGGERS INSTEAD OF INSERT ..................................................................................... 37
TRIGGERS DE AUDITORIA .............................................................................................. 38
Página 4
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
1. ACESSO (LOGINS, GRUPOS E USUÁRIOS)
1.1. LOGINS
Normalmente são gerados 2(dois) logins de acesso a banco:
1(um) para o usuário
1(um) para o usuário ca
AMBIENTE DE PRODUÇÃO
Os logins gerados para este ambiente são:
1(um) para o usuário da Rede
1(um) para o usuário ca_usuário da Rede
Apenas o usuário ca_usuário da Rede tem acesso ao banco de dados, sendo que este é dado
pelo gestor do sistema através da aplicação de Controle de Acesso.
AMBIENTE DE DESENVOLVIMENTO
Os logins gerados para este ambiente são:
1(um) para o projeto (usar o código do projeto cadastrado no ASA)
1(um) para o usuário ca_projeto
O acesso ao banco de dados, via Query Analyzer, para o usuário projeto é solicitado pelo
Coordenador do Sistema que indica o tipo de permissão que deve ser concedida a este. Estes
usuários normalmente são desenvolvedores de sistema.
1.1.1. GRUPOS E USUÁRIOS
Existem dois grupos criados no SQL, para acesso aos bancos de dados:
grp_atualização: acesso para consulta, inclusão, alteração e exclusão ao(s) banco(s)
solicitados
grp_consulta: acesso de leitura ao(s) banco(s) solicitados
Os usuários são incluídos nos grupos através de seus logins, a partir da solicitação do
Coordenador do Sistema.
Página 5
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
2. NOMENCLATURA DE OBJETOS
2.1. CONSIDERAÇÕES GERAIS
Os objetos devem ter nomes formados por uma ou poucas palavras, preferencialmente
substantivos, que os identifiquem da forma mais completa possível para que possa expressar
claramente o seu conteúdo, evitando a utilização de siglas e abreviações desnecessárias e
também observando a cultura da organização e não apenas o contexto do sistema, sempre
visando manter o modelo de dados corporativo da SEFAZ, assim como reutilizar definições já
existentes neste modelo.
Para objetos cuja nomenclatura seja gerenciada pela Ferramenta Case, o limite de tamanho é
determinado pela Ferramenta Case. Para os objetos não definidos através da Ferramenta Case,
deve prevalecer o bom senso no sentido de criar nomes claros, intuitivos e condizentes com a
realidade.
Deve-se utilizar:
 Nomes formados por uma ou poucas palavras (substantivos que os identifiquem);
 Letras minúsculas;
 Palavras no singular;
 Caracter sublinhado (‘_’) como conector de palavras, em lugar de preposição, conjunção ou artigo;
 Preferencialmente palavras em português.
Não se deve utilizar:
 Siglas;
 Abreviações que prejudiquem a clareza do nome do objeto;
 Acentuação ou cedilha;
 Formatação ou caracteres especiais;
 Palavras em outro idioma, exceto quando não for possível encontrar uma palavra na língua
portuguesa que expresse claramente o significado do objeto, ou quando o termo em outro idioma já
for de uso comum de forma que traduzir traga mais um complicador do que usá-lo em outro
idioma. Exemplos: software, hardware, qrcode, token.
NOTA:
Todos os servidores de banco de dados SQL Server da SEFAZ têm como padrão de instalação as
opções code page Multilingual e sort order binary. Toda e qualquer aplicação desenvolvida para
este ambiente deve levar em consideração essas configurações.
Desenvolver aplicações em servidores com configurações diferentes das citadas representa um risco
de surgimento de erros como conflitos de nomes, inconsistência de dados e discrepância de
resultados entre os ambientes de desenvolvimento, homologação e produção.
Página 6
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
2.2. NOMENCLATURA DE OBJETOS DE BANCO DE DADOS
2.2.1. BANCO DE DADOS
O padrão de nomenclatura para os bancos de dados transacionais é:
bd_xxx...xxx
Onde:
 bd é uma abreviatura de Banco de Dados;
 xxx...xxx indica o nome do banco de dados.
Os Padrões de Nomenclatura para os bancos do DW são:
dw_staging_area
Onde:
 dw é uma abreviatura de datawarehouse
 staging_area significa área de armazenamento temporária
dw_dimensao
Onde:
 dw é uma abreviatura de datawarehouse
 dimensao significa área de armazenamento das tabelas de dimensões
dw_fatos...xxx
Onde:
 dw é uma abreviatura de datawarehouse
 fatos significa área de armazenamento das tabelas fatos
 xxx indica o assunto
dw_mddb_views
Página 7
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Onde:
 dw é uma abreviatura de datawarehouse
 mddb_views significa área de armazenamento das views de acesso via Hyperion
dw_credito_views
Onde:
 dw é uma abreviatura de datawarehouse
 credito_views significa área de amazenamento das views de acesso via Access
2.2.2. STORED PROCEDURES
O padrão de nomenclatura para as Stored Procedures é:
up_vvv...vvv_ddd...ddd
Onde:
 up é uma abreviatura de User Procedure
 vvv...vvv é um verbo no infinitivo
 ddd...ddd é um nome livre
Exemplo: Caso seja criada uma Stored Procedure para calcular o valor do auto de infração, o
nome desse objeto deveria ser up_calcular_valor_auto_infracao.
NOTA:
Para procedures de cargas do DW o verbo no infinitivo “vvv...vvv” deverá ser substituído por
“cg”.
Exemplo: up_cg_fat_indicador_credito
O padrão de nomenclatura para Variáveis e Parâmetros nas procedures é:
yyy_vvvvvvvvvvvv
Onde:
 yyy indica o tipo do atributo definido (Atributo)
 vvvvvvvvvvvv indica o nome da variável
Página 8
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
2.2.3. USER FUNCTIONS
O padrão de nomenclatura para as User Functions é:
uf_ddd...ddd
Onde:
 uf é uma abreviatura de User Function
 ddd...ddd é um nome livre, que NÃO deve iniciar com um verbo e sim com um termo que indique
o dado que será retornado através dessa função.
Exemplo: Caso seja criada uma User Function para retornar o próximo dia útil, o nome desse
objeto poderia ser uf_dia_util.
NOTA:
Antes de criar uma função, deve-se consultar a equipe de DBA para verificar a sua real necessidade.
Fora isso, deve-se verificar também a pré-existência de alguma função que possa ser reutilizada.
O padrão de nomenclatura para Variáveis e Parâmetros nas user functions é:
yyy_vvvvvvvvvvvv
Onde:
 yyy indica o tipo do atributo definido (Atributo)
 vvvvvvvvvvvv indica o nome da variável
2.2.4. TRIGGERS
O padrão de nomenclatura para os triggers de integridade referencial é:
tg_ref_ttt...ttt_ooo
Onde:
 tg é uma abreviatura de trigger
 ref indica que é trigger de integridade referencial
 ttt...ttt indica o nome da entidade
 ooo indica o tipo da operação efetuada
“ins” para trigger de insert
“upd” para trigger de update
“del” para trigger de delete
O padrão de nomenclatura para os triggers de negócio é:
tg_neg_ttt...ttt_ooo
Onde:
Página 9
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação




29/05/2017
tg é uma abreviatura de trigger
neg indica que é trigger de negócio
ttt...ttt indica o nome da entidade
ooo indica o tipo da operação efetuada
“ins” para trigger de insert
“upd” para trigger de update
“del” para trigger de delete
O padrão de nomenclatura para os triggers de auditoria é:
tg_ttt...ttt_aud
Onde:
 tg é uma abreviatura de trigger
 ttt...ttt indica o nome da entidade
 aud indica que é trigger de auditoria
Se a entidade for um nome composto, caso seja necessário, pode-se abreviá-lo, porém deve-se
manter o sublinhado (_) separando os nomes e contemplar todas as “partes” que compõe o
nome da entidade.
Exemplo: Caso seja criado o trigger de negócio para a operação de insert da tabela
ocorrencia_movim_fisc_autom,
o
nome
do
trigger
poderia
ser
tg_neg_ocorr_mov_fisc_autom_ins, mas não tg_neg_ocorr_fisc_autom_ins, por exemplo,
pois o nome da tabela não foi totalmente contemplado (retirou a parte mov).
NOTAS:
O Manual de Procedimentos Gerais de Sistemas aborda algumas considerações
sobre triggers.
O SQL 2000 permite a criação de triggers INSTEAD OF, mas os mesmos NÃO devem ser
utilizados, pois a criação de um trigger INSTEAD OF em uma tabela omite a execução dos demais
triggers (AFTER) para a mesma operação naquela mesma tabela. A única indicação para uso desse
trigger é o caso de tabelas que devem possuir apenas uma linha (como as tabelas utilizadas para
geração de números seqüenciais e as tabelas de parâmetros de sistema).
Para verificar o padrão para a criação de triggers deve-se consultar o item 4 – Padrão de
Layout de Triggers
2.2.5. VIEWS
Antes de efetuar a criação de qualquer view, deve-se consultar o Manual de Procedimentos
Gerais de Sistemas. Nesse documento existe um tópico que relaciona considerações sobre a
criação desses objetos de banco.
2.2.5.1.
VIEWS COMUNS
Página 10
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
O padrão de nomenclatura para as Views comuns é:
vw_ttt...ttt
Onde:
 vw é uma abreviatura de View
 ttt...ttt é um nome que descreve a view. O nome da view deve contemplar o assunto que ela trata e
não os nomes das tabelas envolvidas.
2.2.5.2.
VIEWS DE REPLICAÇÃO
O padrão de nomenclatura para as Views de Replicação é:
vr_ttt...ttt
Onde:
 vr é uma abreviatura de View de Replicação
 ttt...ttt é um nome que descreve a view. O nome da view deve contemplar o assunto que ela trata e
não os nomes das tabelas envolvidas.
NOTA:
As views de Replicação só devem ser criadas pela GETEC.
2.2.5.3.
VIEWS DE LINKED SERVER
O padrão de nomenclatura para as Views de Linked Server é:
vl_ttt...ttt
Onde:
 vl é uma abreviatura de View de Linked Server
 ttt...ttt é o nome da tabela que a view referencia.
Exemplo:
Um trigger no servidor S1 precisa acessar a tabela tab no servidor SSED03W. Logo, uma
view chamada vl_tab será criada em S1 com o seguinte código:
CREATE VIEW vl_tab AS
SELECT campo1, campo2, ...
FROM CORPORATIVO.nome_do_banco.dbo.tab
Local para criação de Views de Linked Server:
Banco: bd_linked
2.2.5.4.
VIEWS INDEXADAS
O padrão de nomenclatura para as Views Indexadas é:
vi_ttt...ttt
Página 11
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Onde:
 vi é uma abreviatura de View Indexada
 ttt...ttt é um nome que descreve a view. O nome da view deve contemplar o assunto que ela trata e
não os nomes das tabelas envolvidas.
NOTA:
Devido às restrições existentes em relação ao uso de Views Indexadas, o analista que identificar
a necessidade de utilização das mesmas deve conversar previamente com a GETEC (DBA e
AnalistaDO
de DW
Performance).
VIEWS
Só deve ser
2.2.5.5.
VIEWS DO DW
O Padrão específico de Nomenclatura para as Views do DW, quando estas representarem
apenas uma tabela e não possuírem nenhuma cláusula de restrição, é:
ttt...ttt
Onde:
 ttt...ttt é o mesmo nome da tabela a ser disponibilizada para a camada semântica de
abstração.
Exemplo:
Uma view para representar a tabela fato fat_indicador_credito deverá se chamar
fat_indicador_credito
Entretanto, quando as views representarem uma consulta que envolva mais de uma tabela e/ou
contiverem alguma cláusula de restrição, o padrão de nomenclatura a ser seguido deverá ser
aquele já estabelecido neste documento no item 2.2.5.1 – VIEWS COMUNS.
Exemplo:
Uma view que representar uma consulta à tabela fato fat_indicador_credito e, na
intenção de restringir os dados ao ano corrente, à dimensão dim_tempo poderá se chamar
vw_indicador_credito_atual
NOTA:
As views são criadas no banco dw_mddb_views para representarem uma camada de abstração que
omita da ferramenta OLAP certos detalhes técnicos como, por exemplo, os nomes de bancos de
dados, de campos seqüenciais.
2.2.6. PACOTES DTS DO DW
O padrão de nomenclatura para os Pacotes de Download de Dimensões do DW é:
pck_dwh_dim_ddd...ddd
Página 12
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Onde:
 pck_dwh é uma abreviatura de pacote de DW
 dim é uma abreviatura de Dimensão
 ddd...ddd é um nome livre
O padrão de nomenclatura para os Pacotes de Download de Fatos do DW é:
pck_dwh_fat_ddd...ddd
Onde:
 pck_dwh é uma abreviatura de pacote de DW
 fat é uma abreviatura de Fato
 ddd...ddd é um nome livre
NOTA:
Os pacotes de download são gerados a partir do Enterprise Manager e têm como objetivo carregar
as tabelas auxiliares que serviram como base para a carga das tabelas de dimensão e fato.
O padrão de nomenclatura para os Pacotes de Carga de Dimensões do DW é:
pck_dwh_proc_dim_ddd...ddd
Onde:




pck_dwh é uma abreviatura de pacote de DW
proc é uma abreviatura de procedure
dim é uma abreviatura de Dimensão
ddd...ddd é um nome livre
O padrão de nomenclatura para os Pacotes de Carga de Fatos do DW é:
pck_dwh_proc_fat_ddd...ddd
Onde:




pck_dwh é uma abreviatura de pacote de DW
proc é uma abreviatura de procedure
fat é uma abreviatura de Fato
ddd...ddd é um nome livre
O padrão de nomenclatura para os Pacotes de ações que não sejam carga de tabelas Fatos
ou Dimensões do DW é:
pck_dwh_vvv…vvv_ddd...ddd
Página 13
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Onde:
 pck_dwh é uma abreviatura de pacote de DW
 vvv...vvv é um verbo no infinitivo
 ddd...ddd é um nome livre
Exemplo:
O pacote DTS para limpar a área de Staging pode ter o nome
pck_dwh_limpar_staging.dts
NOTA:
Os pacotes de carga são gerados a partir do Enterprise Manager e têm como objetivo carregar as
tabelas de dimensão e fato.
2.2.7. CUBOS DO DW
O padrão de nomenclatura para os Cubos do DW é:
cb_ddd…..ddd
Onde:
 cb é uma abreviatura de cubo de DW
 ddd...ddd é um nome livre que deve detalhar o assunto
NOTA:
Os Cubos são criados para armazenar dados em uma estrutura multidimensional de fácil navegação.
Podem
ser previamente
VIRTUAIS
CUBOS calculados, otimizando o tempo de recuperação das informações.
O padrão de nomenclatura para os Cubos Virtuais do DW é:
vc_ddd…..ddd
Onde:
 vc é uma abreviatura de virtual cubo DW
 ddd...ddd é um nome livre que deve detalhar o assunto
NOTA:
Cubo virtual é um conjunto de cubos, similar às views em uma base de dados relacional.
Página 14
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
2.2.8. DATA SOURCE NAME (DSN)
O padrão de nomenclatura para os Data Source Name é:
dsn_xxx...xxx
Onde:
 xxx...xxxxx indica o tipo do Servidor ( Desenvolvimento ou Produção)
Atualmente só devem existir 3 (três) DSN´s:



dsn_desenvolvimento (SSED20W)
dsn_desenvolvimento_web (SSED02W)
dsn_producao (SSED03W)
NOTA:
Essa nomenclatura só é necessária para aplicações WEB.
2.2.9. ESTATÍSTICAS DE BANCO
O padrão de nomenclatura para as Estatísticas de Banco é:
est_xxx...xxx_nnn...nnn
Onde:
 xxx...xxxx indica o nome da tabela
 nnn...nnn indica o nome do campo
Exemplo: Estatística do campo num_placa_cavalo para a tabela passe_fiscal:
est_passefiscal_numplacacavalo
Apesar de ser possível a criação de uma estatística para um conjunto de campos, o SQL
Server sempre sugere a criação das estatísticas para cada campo individualmente.
NOTA:
A criação de estatísticas de banco só pode ser efetuada pela GETEC. Caso o analista precise
criar alguma, deve enviar um chamado para _Atendimento GEPIN AD.
2.2.10. SERVIDOR
O padrão de nomenclatura para Servidores é:
Página 15
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
XYYY...YYY
Onde:
 X indica o ambiente, onde:
 Desenvolvimento: d
 Homologação Interna: h
 Homologação Externa: e
 Produção: p
YYY...YYY indica o nome lógico do servidor ou sua abreviação;
 O nome do servidor deve possuir até quinze caracteres.
2.2.11. INSTÂNCIAS
2.2.11.1. INSTÂNCIA PADRÃO
O padrão de nomenclatura para as Instâncias Padrão é:
xxx...xxx
Onde:
 xxx...xxx indica o nome do servidor:
NOTA:
Este tipo de instância deve ser evitado, sempre que possível.
2.2.11.2. INSTÂNCIA NOMEADA
O padrão de nomenclatura para as Instâncias Nomeadas é:
xxy_zzz...zzz
Onde:
 xx indica o nome do servidor:
 Servidor de Banco de Dados: bd
 y indica o ambiente:
 Desenvolvimento: d
 Homologação Interna: h
 Homologação Externa: e
 Produção: p
 zzz...zzz indica o nome da instância propriamente dita ou sua abreviação, devendo cada palavra ser
separada da outra pelo “_”
NOTA:
O nome da instância pode ter até 16 caracteres e deve seguir as regras contidas no Books
Online. A GETEC recomenda a utilização de até 15 caracteres p/ nomear a instância,
evitando alterações na migração para o SQL 2005 (esta é a limitação de Virtual Server SQL 2005).
Página 16
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
2.2.12. SCHEMAS
O padrão de nomenclatura para os Schemas é:
nnnnnn
Onde:
 nnnnnn é um nome que identifique o negócio.
NOTA:
Válido apenas para o SQL Server 2005.
2.2.13. SINÔNIMOS
O padrão de nomenclatura para os Sinônimos é:
xxxxxx
Onde:
 xxxxxx é o mesmo nome do objeto ao qual se refere.
Os sinônimos podem ser locais ou remotos.
NOTA:
Válido apenas para o SQL Server 2005. Todos os sinônimos deverão estar no schema dbo,
por isso não é permitido criar objetos diferentes com mesmo nome.
2.2.14. LINKED SERVER
O padrão de nomenclatura para os Linked Servers é:
yyyyyy
Onde:
 yyyyyy é um nome que identifique o negócio, por instância.
Atualmente existem os seguintes Linked Servers:
Página 17
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação





29/05/2017
CORPORATIVO (PCORPORATIVO\BDP_CORPORATIVO)
SINTEGRA (PSINTEGRA\BDP_SINTEGRA)
NFEN (BDP_NFEN)
DATAWAREHOUSE (PDW\BDP_DW)
PROCESSAMENTO (BDP_NFEN_PROCESS)
2.2.15. NOMES LÓGICOS DOS SERVIDORES
O padrão de nomenclatura para os Nomes Lógicos dos Servidores é:
yyyyyy
Onde:
 yyyyyy é um nome que identifique o negócio ou serviço.
Exemplos: CORPORATIVO, NFEN.
2.2.16. INSTÂNCIAS POR NOME LÓGICO DOS SERVIDORES
O padrão de nomenclatura para as instâncias por nome lógico dos servidores é:
xxx...xxx\yyy...yyy
Onde:
 xxx...xxx é um nome que identifica o servidor.
 yyy...yyy é um nome que identifica a instância.
 \ - Parte fixa que une a identificação do servidor e da instância.
NOTA:
Instância por nome lógico dos servidores suporta até 32 caracteres contemplando os sinais
de sublinhado e barra invertida.
Atualmente existem as seguintes Instâncias por Nomes Lógicos dos Servidores:
NOME LÓGICO DO SERVIDOR
INSTÂNCIA
HOMOLOGAÇÃO
EXTERNA
DESENVOLVIMENTO
HOMOLOGAÇÃO
CORPORATIVO
DCORPORATIVO\
BDD_CORPORATIVO
HCORPORATIVO\
BDH_CORPORATIVO
-
PCORPORATIVO\
BDP_CORPORATIVO
SINTEGRA
DSINTEGRA\
BDD_SINTEGRA
HSINTEGRA\
BDH_SINTEGRA
-
PSINTEGRA\
BDP_SINTEGRA
NFEN
DNFEN\BDD_NFEN
-
HNFEN\BDE_NFEN
BDPNFEN\BDP_NFEN
DATAWAREHOUSE
DDW\BDD_DW
HDW\BDH_DW
-
PDW\BDP_DW
PROCESSAMENTO
DNFEN\BDD_NFEN_
PROCESS
-
HNFEN\
BDE_NFEN_PROCESS
Página 18
PRODUÇÃO
BDPNFENPROCESS\
BDP_NFEN_PROCESS
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
DNFENREC\
BDD_NFEN_REC_A
RECEPCAO
DBINFEN\
BDD_BINFEN
(Report, Analysis
server, Staging)
BINFEN
-
HBINFEN\
BDH_BINFEN
(Analysis server,
Staging)
HENFENRECA\
BDE_NFEN_REC_A
PNFENRECA\
BDP_NFEN_REC_A
HENFENRECB\
BDE_NFEN_REC_B
PNFENRECB\
BDP_NFEN_REC_B
HNFENRECC\
BDE_NFEN_REC_C
PNFENRECC\
BDP_NFEN_REC_C
-
HBINFENRS\
BDH_BINFEN_RS
(Report)
PBINFENAS\
BDP_BINFEN_AS
(Analysis server)
PBINFEN\BDP_BINFEN
(Staging)
INTELLINX
-
-
-
10.9.249.252
(PRODEB)
SAEB
-
-
-
10.2.8.234
(SAEB)
EFD
DEFD\BDD_EFD
HEFD\BDH_EFD
-
PEFD\BDP_EFD
HYPERION
-
SSED239W
-
SSED225W
DW ANALYSIS SERVICE
-
-
-
SSED224W
URA
-
-
-
SSED17W
BCL
DBCL\BDD_BCL
HBCL\BDH_BCL
-
-
BCL_RECEPCAO
DBCLRECA\
BDD_BCL_REC_A
HBCLRECA\
BDH_BCL_REC_A
-
-
BCL_PROCESSAMENTO
DBCL\
BDD_BCL_PROCESS
HBCL\
BDH_BCL_PROCESS
-
-
NFCE
DNFCE\BDD_NFCE
HNFCE\BDH_NFCE
-
-
MFC
DMFC\BDD_MFC
HMFC\BDH_MFC
-
PMFC\BDP_MFC
NOTA:
Caso seja necessário criar um linked server, este deverá ter o nome igual ao nome lógico
do servidor.
2.2.17. JOBS
O padrão de nomenclatura para JOBs de negócio é:
neg_xxx...xxxx_ppppp
Onde:
 xxx...xxxx é a descrição do JOB
 ppppp é o código do projeto
Página 19
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
O padrão de nomenclatura para JOBs administrativos é:
adm_xxx...xxxx_getec
Onde:
 xxx...xxxx é a descrição do JOB
2.2.18. FILAS
O padrão de nomenclatura para filas do service broker é:
fila_fff...fff
Onde:
 fff...fff é o nome da fila
2.2.19. ENTIDADE
O padrão de nomenclatura para as Entidades é:
ttt...ttt
Onde:
 tttt...tttt indica o nome da tabela
NOTA:
Se a entidade for uma entidade associativa, caso não exista um nome específico no mundo
real que identifique o que ela representa, deve-se fazer uma composição dos nomes das
tabelas associadas, de forma a se poder identificar quem são elas. Deve-se manter o “_” como
separador das diversas partes do nome.
O padrão de nomenclatura para as Tabelas Temporárias é:
tmp_ttt...ttt
Onde:
 tmp é uma abreviatura de temporária
 tttt...tttt indica o nome da tabela
NOTA:
Esse padrão deve ser aplicado para as tabelas cujo conteúdo sempre será excluído antes da
execução de algum procedimento. (Exemplo: Tabelas temporárias usadas para armazenamento
de dados que serão exibidos em um relatório). As tabelas temporárias que são criadas apenas
durante a execução da consulta (query) – tabelas que possuem o símbolo # - não precisam seguir
esse padrão. Convém destacar que no Manual de Boas Práticas SQL existem considerações
sobre o uso dessas tabelas.
Página 20
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
O padrão de nomenclatura para os Consolidados é:
cons_ ttt...ttt
Onde:
 cons é uma abreviatura de consolidado
 tttt...tttt indica o nome da tabela
O padrão de nomenclatura para as Tabelas de Histórico é:
hist_ ttt...ttt
Onde:
 hist é uma abreviatura de histórico
 tttt...tttt indica o nome da tabela
O padrão de nomenclatura para as Tabelas de Auditoria é:
aud_ ttt...ttt
Onde:
 aud é uma abreviatura de auditoria
 tttt...tttt indica o nome da tabela que será auditada.
Exemplo: Se a tabela a ser auditada chama-se contribuinte_inscrito, o nome da tabela de
auditoria deve ser aud_contribuinte_inscrito.
O padrão de nomenclatura para as Tabelas Particionadas é:
ttt...ttt_cccc
Onde:
 tttt...tttt indica o nome da tabela
 cccc é o critério utilizado para o particionamento como: ano, semestre, situação, etc.
Exemplo: Se o critério utilizado para o particionamento da tabela tef_operacao_ecf for o ano,
o nome da tabela referente ao ano de 2004 deverá ser tef_operacao_ecf_2004.
NOTAS:
Convém destacar que no Manual de Procedimentos Gerais de Sistemas (item Procedimento
para Tratamento de Tabelas Com Grande Quantidade De Registros) existem considerações
NOTAS:
sobre estratégias para tratamento de tabelas com grande quantidade de registros.
Sempre que for necessário reduzir o nome da entidade para compor algum objeto do banco de
dados, deve-se:
 Reduzir preferencialmente o nome da primeira entidade.
 Reutilizar o nome reduzido para os outros objetos do banco de dados.
Página 21
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Ao referenciar entidades, deve-se sempre considerar o descrito no item Independência de
Codificação deste manual.
O padrão de nomenclatura para as Tabelas Auxiliares do DW é:
aux_ ttt...ttt
Onde:
 aux é uma abreviatura de auxiliar
 tttt...tttt indica o nome da tabela
Exemplo: Se a tabela se chama auto_infracao, o nome da tabela auxiliar deve ser
aux_auto_infracao.
NOTA:
Tabelas auxiliares são cópias de produção e auxiliam no processo de transformação e carga dos
dados.
O padrão de nomenclatura para as Tabelas de Dimensões do DW é:
dim_ddd...ddd
Onde:
 dim é uma abreviatura de Dimensão
 ddd...ddd é um nome livre
NOTA:
As dimensões são tabelas que armazenam as informações descritivas.
O padrão de nomenclatura para as tabelas de agrupamento do DW é:
agr_ddd...ddd
Onde:
 agr é uma abreviatura de agrupamento
 ddd...ddd é um nome livre
NOTA:
Página 22
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
Os agrupamentos são tabelas que armazenam as informações de forma consolidada e auxiliam
na carga das tabelas fatos.
O padrão de nomenclatura para as Tabelas de Fatos do DW é:
fat_ddd...ddd
Onde:
 fat é uma abreviatura de Fato
 ddd...ddd é um nome livre
NOTA:
Fatos são tabelas que armazenam as métricas.
O padrão de nomenclatura para as Tabelas de Controle de execução de cargas do DW é:
ctr_ddd...ddd
Onde:
 ctr é uma abreviatura de Controle
 ddd...ddd é um nome livre
NOTA:
As Tabelas de Controle armazenam a situação e a data de execução das cargas.
2.2.20. ATRIBUTO
O padrão de nomenclatura para os Atributos é:
yyy_ aaa...aaa
Onde:
 yyy indica o tipo do atributo
 aaa...aaaa é um qualificador do atributo
O tipo do atributo deverá ser um dos códigos abaixo.
ano
des
dig
dtr
hor
nom
=
=
=
=
=
=
Ano
Descrição
Digito
Data Reduzida (ano/mês, dia/mês ou mês/ano)
Hora
Nome
Página 23
cod
dia
dtc
fon
mes
num
=
=
=
=
=
=
Código
Dia
Data completa
Fonético
Mês
Número
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
prc
seq
sts
img
=
=
=
=
29/05/2017
Percentual
Sequencial
Status
Imagem
qtd
sig
val
Xml
=
=
=
=
Quantidade
Sigla
Valor
Arquivo XML
NOTA:
dtr – pode estar no formato int ou smallint
int => armazenamento de ano e mês ou ano e dia. Quando usar o ano, fazê-lo com 4 dígitos
smallint => armazenamento de mês e dia.
ano – deve ter 4 digitos.
sig - quando o domínio de um campo não for binário (não contemplar apenas Sim ou não,
Verdadeiro ou Falso) e que não possa ser tabelado (não possuir tabela básica correspondente).
sts – quando o domínio for estritamente binário (contemplar apenas Sim ou não, Verdadeiro ou
Falso).
cod - quando o domínio de um campo puder ser tabelado (possuir tabela básica correspondente).
Os nomes dos campos de código, descrição, nome de tabelas de domínio, devem seguir os
nomes das tabelas. Estes nomes podem ser abreviados quando necessário, desde que o
significado do mesmo seja claro e o nome completo da tabela seja preservado. Deve ser
mantido o caracter “_” para separar as palavras que compõe o nome.
Exemplo I: Nome da tabela mensagem_erro
Os nomes dos atributos dessa tabela podem ser:
cod_mensagem_erro ou cod_mens_erro
des_mensagem_erro ou des_mens_erro
num_prioridade
dtc_atualizacao
Exemplo II: Nome da tabela ocorrencia_movim_fisc_autom
Os nomes dos atributos dessa tabela podem ser:
cod_ocorrencia_mov_fisc_autom ou cod_ocor_mov_fisc_autom
des_ocorrencia_mov_fisc_autom ou des_ocor_mov_fisc_autom
des_ocorrencia_mov_fisc_autom_resumida ou des_ocor_mov_fisc_autom_resumida
dtc_inicio_vigencia
dtc_fim_vigencia
dtc_atualizacao
Nesse caso, os nomes desses campos não podem ser, por exemplo, des_ocorr_fisc_autom,
pois não contempla todo o nome da tabela (a parte movim foi omitida).
NOTAS:
O Manual de Procedimentos Gerais de Sistemas relata algumas considerações sobre o uso
de atributos.
Ao referenciar atributos, deve ser sempre considerado o descrito no item Independência de
Codificação deste manual.
2.2.20.1. ATRIBUTO FONETIZADO
Página 24
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
O padrão de nomenclatura para os atributos fonetizados é:
fon_ aaa...aaan
Onde:
 yyy indica o tipo do atributo fonetizado
 aaa...aaaa é um qualificador do atributo
 n é um número de 1 a 4, visto que sempre serão criados 4 atributos para cada um a ser fonetizado
NOTA:
Este atributo será sempre do tipo Char, tamanho 4 e podendo ser nulo. O tamanho dos
nomes dos atributos fonetizados também é limitado pela ferramenta Case.
2.2.20.2. TIPO DE DADOS
Tipos de dados especificam as características dos atributos, parâmetros de stored procedures e
variáveis.
Na ferramenta CASE devem ser definidos os campos de acordo com os tipos do SQL Server
listados na tabela a seguir:
SQL SERVER
CHAR (n)
ACCESS
TEXTO
VARCHAR (n)
TEXTO
DESCRIÇÃO
Permite valores alfanuméricos. Sempre reserva os n
caracteres definidos para o campo. Deve ser usado para
campos de código e para pequenas descrições onde o
número de caracteres inseridos não variar muito,
ficando próximo do limite definido.
Permite valores alfanuméricos com no máximo 8.000
caracteres. Como o tamanho total da tabela é 8 Kb,
deve-se atentar para não exceder esse limite, uma vez
que o tamanho dos campos varchar não está
pré-definido. Deve ser usado para campos descritivos
de uma maneira geral, desde que não se encaixem na
situação definida para CHAR. Constantes alterações em
campos do tipo varchar podem implicar em
reorganizações físicas e conseqüente overhead nos
updates.
Permite datas de 01/Jan/1753 até
31/Dez/9999 e hora/minutos/segundos/milesegundos
(no formato 00:00:00:000AM/PM), registrados juntos
no
mesmo campo.
Armazena o número em 8 bytes, sendo 2 grupos de
4 bytes inteiros.
Pode ser informado só a data ou só a hora. Quando
nenhum dos dois for informado, o default é
DATETIME
Página 25
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
SMALLDATETIME DATA/HORA
INT
NUMERO/
INTEIROLONGO
BIGINT
SMALLINT
NUMERO/INTEIRO
TINYINT
NUMERO/BYTE
MONEY
MOEDA
DECIMAL ( p [, s ] )
Página 26
01/Jan/1900 12:00:00:000AM.
Valores são movidos para o campo com aspas simples
(´).
A função CONVERT deve ser utilizada para resgatar
somente a data ou hora, variando seu formato.
Insere e recupera o dado inteiro (Data/Hora)
Permite datas de 01/Jan/1900 até 06/Jun/2079 (no
formato mm/dd/aaaa) e hora/minutos, registrados
juntos no mesmo campo. Armazena o número em 4
bytes.
Quando somente for informada a data, a hora default é
12:00AM, e quando somente for informada a hora,
a data default é Jan 1, 1900.
Valores são movidos para o campo com aspas simples
(´). A função CONVERT deve ser utilizada para
resgatar somente a data ou hora, variando seu formato.
Insere e recupera o dado inteiro (Data/Hora)
Permite números inteiros de
-2.147.483.648 até 2.147.483.647, ou seja, -2(31) até
2(31) -1. Armazena o número em 4 bytes. Indicado
para números inteiros com até 9 caracteres.
Permite números inteiros acima de
-9.223.372.036.854.775.808.
Armazena o número em 8 bytes.
Indicado para números inteiros acima de 10 e abaixo
de 19 caracteres. Acima de 19 caracteres, para
números inteiros, deve ser usado o tipo Decimal.
Permite números inteiros de -32.768 até 32.767, ou
seja, -2(15) até 2(15) -1. Armazena o número em 2
bytes.
Permite números inteiros de 0 até 255. Armazena o
número em 1 byte.
Indicado para campos com limitação de tamanho.
Indicado para campos do tipo status(nesses casos
deve-se associar uma constraint Check para validar os
dados).
Permite números com precisão para 15 inteiros e 4
decimais, tendo valor máximo 2(63) e mínimo, -2(63).
Armazena o número em 8 bytes. Esse tipo de dado só
deve ser usado quando todas as 4 casas decimais
forem
preenchidas ou quando não for necessária a
conversão do dado (aproximação).
Caso sejam utilizadas menos que 4 casas decimais
e seja necessário efetuar a conversão de valores,
esse tipo de dado não deve ser usado. Caso sejam
utilizadas menos que 4 casas decimais
e não seja necessário efetuar a conversão de valores,
esse tipo de dado pode ser usado.
Permite números, com ou sem decimais, de
-10 (38) até 10 (38) - 1, preservando a precisão até
o último dígito significativo (precisão engloba tanto
a parte decimal como a parte inteira).
Armazena o número em 5 até 17 bytes, dependendo do
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
tamanho total declarado (p), inclusive contando com as
casas decimais especificadas no parâmetro [s].
Precisão Tam.Bytes
1 -9 = 5
10-19 = 9
20-28 = 13
29-38 = 17
Consiste em um campo resultante de operações
efetuadas em outros campos da tabela. No SA, esse tipo
de dado deve ser criado como Definido pelo Usuário.
Armazena arquivo XML. Tipo válido apenas para o
SQL Server 2005 e 2008. Este tipo especial de dados
permite que o conteúdo de um arquivo XML seja
armazenado de forma que sua estrutura hierárquica seja
padronizada através de um Schema e consultada através
de XQuery. Há facilidade na manipulação do conteúdo
do XML.
Apesar das vantagens, esse tipo de campo altera a
estrutura original do XML, não sendo indicado onde é
necessário garantir a integridade do dado armazenado.
Em alguns casos, o armazenamento do tipo de dado
XML invalida a assinatura do arquivo XML. Esse tipo
de dado ocupa mais espaço e é menos performático que
o tipo VARBINARY, sendo que para a manipulação
através desse último tipo, faz-se necessário converte-lo
para VARCHAR(Max). Em um XML pequeno e com
até 1000 registros a Xquery funciona perfeitamente,
porém em um XML extenso e complexo fica
impraticável.
Suporta até 2GB de dados e deve ser usado quando o
tamanho exceder 8000 bytes. A interferência no
tamanho máximo de um registro (8 Kb) é mínima, pois
armazena apenas um ponteiro para as páginas de dados.
Tipo válido apenas para o SQL Server 2005.
Os tipos de dados binary e varbinary armazenam
cadeias de caracteres de bits. Embora os dados dos
caracteres sejam interpretados com base na página de
código SQL Server, os dados binary e varbinary são
simplesmente um fluxo de bits.
Deve ser usado quando o tamanho do dado é fixo,
sendo que n varia de 1 a 8000.
Os tipos de dados binary e varbinary armazenam
cadeias de caracteres de bits. Embora os dados dos
caracteres sejam interpretados com base na página de
código SQL Server, os dados binary e varbinary são
simplesmente um fluxo de bits.
Varbinary (n) deve ser usado quando o tamanho do
dado variar consideravelmente. n pode variar de 1 a
8000.
Deve-se utilizar varbinary(Max) quando os dados
excederem 8000 bytes.
COMPUTED
XML
VARCHAR (Max)
BINARY (n)
VARBINARY [ ( n |
max) ]
Página 27
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
NOTA:
O SQL 2000 permite ainda a criação de outros tipos de dados como Table , sql_variant. Sobre o tipo
Table deve-se seguir suas recomendações de uso de acordo com o Manual de Boas Práticas SQL.
Os tipos de dados sql_variant ainda não foram estudados o suficiente e, em face disso, NÃO podem
ser utilizados.
2.2.21. CONSTRAINTS
O banco de dados implementa a integridade dos dados através da criação de constraints
(regras de consistência): Chave Primária (Primary Key), Chave Estrangeira (Foreign Key),
Checks (Domínio de Valores) e Valores Default.
2.2.21.1. CHAVE PRIMÁRIA
O padrão de nomenclatura para a chave primária é:
ix_tttt01
Onde:
 ix identifica Índice
 tttt...tttt indica o nome da entidade
 01 é número seqüencial que indica que um índice é uma chave primária.
Se a entidade for um nome composto, e sendo necessário, pode-se abreviá-lo, porém deve-se
manter o sublinhado ( _ ) separando os nomes e todas as “partes” que compõe o nome da
tabela devem ser contempladas.
Exemplo: Caso o nome da tabela seja ocorrencia_movim_fisc_autom, o nome da chave
primária
poderia
ser
ix_ocorr_mov_fisc_autom01,
mas
não
poderia
ser
ix_ocorr_mov_autom01, pois não contempla todos as partes do nome da tabela (a parte fisc
foi retirada)
2.2.21.2. ÍNDICE SECUNDÁRIO
O padrão de nomenclatura para índice secundário é:
ix_ttttnn
Onde:
 ix identifica Índice
 tttt...tttt indica o nome da entidade
 nn é número seqüencial para índices por entidade. Deve começar do 02, visto que o
seqüencial 01 identifica chave primária.
Exemplo: Segue as mesmas regras de formação da nomenclatura da constraint chave
primária, devendo apenas obedecer ao início do seqüencial em 02. Dessa forma, caso o nome
de uma tabela seja ocorrencia_movim_fisc_autom, o nome de um índice secundário poderia
Página 28
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
ser ix_ocorr_mov_fisc_autom02, mas não poderia ser ix_ocorr_mov_autom02, pois não
contempla todos as partes do nome da tabela (a parte fisc foi retirada).
NOTA:
Índices secundários únicos devem ser criados sempre como índice e não como
constraint. Exemplo:
Utilizar
CREATE UNIQUE NONCLUSTERED INDEX ix_lacre_termo_ecf02
ON lacre_termo_ecf (num_lacre_termo)
Não utilizar
ALTER TABLE lacre_termo_ecf ADD
CONSTRAINT ix_lacre_termo_ecf02
UNIQUE NONCLUSTERED (num_lacre_termo)
2.2.21.3. ÍNDICE PARA TESTES DE PERFORMANCE
O padrão de nomenclatura para índices para testes de performance é:
tp_ttttnn
Onde:
 tp identifica que é um índice para teste de performance
 tttt...tttt indica o nome da entidade
 nn é número seqüencial para índices por entidade.
Um índice para teste de performance é um índice provisório que só pode ser criado pela
GETEC.
NOTA:
O Manual de Procedimentos Gerais de Sistemas relata algumas
considerações sobre o uso de índices para testes de performance.
2.2.21.4. CHAVE ESTRANGEIRA
O padrão de nomenclatura para a chave estrangeira é:
fk_ffff...ffff_ppp..pppnn
Onde:
 fk é uma abreviatura de Foreign Key
Página 29
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
 fff...fff indica o nome da entidade onde o atributo será "fk"(entidade filha) (Ver desenho)
 ppp...pp indica o nome da entidade onde o atributo ("fk") compõe a primary key(entidade pai)
(Ver desenho)
 nn é um seqüencial de identificação
PAI
Os nomes das entidades podem ser abreviados, atentando sempre para
contemplar todas as “partes” que compõe o nome da tabela.
O sublinhado ( _ ) deve existir somente para separar o nome da
entidade pai do nome da entidade filha, bem como para separar o
nome da entidade filha do prefixo “fk”. Ele não deve seu usado
apenas como separador de campo do nome da entidade pai ou do
nome da entidade filha.
FILHA
Exemplo: Considerando que a tabela ocorrencia_movim_fisc_autom é filha da tabela
tipo_ocorrencia_movim_fisc_autom,
o
nome
da
fk
poderia
ser
fk_ocomovfisaut_tpocomovfisaut01,
mas
não
poderia
ser
fk_oco_mov_fisc_aut_tp_mov_fis_aut (o caracter “ _ ” está sendo usado como separador para
o nome das tabelas filha e pai), nem fk_ocomovfisaut_tpocomovaut01 (não contempla
todas as partes que compõe o nome da tabela, pois a parte fisc foi retirada) e nem
fk_ocomovfisaut_tpocomovfisaut pois não está com o seqüencial de identificação.
2.2.21.5. CHECK
Domínio é o conjunto de valores que um determinado atributo pode assumir. Para delimitar
esse conjunto, usa-se a Constraint Check
O padrão de nomenclatura para check é:
ck_ttt...ttt_xxx...xxx
Onde:
 ck é uma abreviatura de Check
 ttt...ttt indica o nome da entidade
 xxx...xxx indica o nome do atributo
Os nomes da entidade e do atributo podem ser abreviados, atentando sempre para contemplar
todas as “partes” que compõe os nomes dos mesmos.
O sublinhado ( _ ) deve existir somente para separar o nome da entidade do nome do atributo,
bem como para separar o nome da entidade do prefixo “ck”. Ele não deve ser usado apenas
como separador de campo do nome da entidade ou do nome do atributo.
Exemplo:
Na
tabela
ocorrencia_movim_fisc_autom
existe
o
campo
sts_ocorr_movim_fisc_autom, o qual possui um check indicando que os valores válidos são
“N” ou “S”. O nome do Check poderia ser ck_ocmovfisaut_stsocmovfisaut, mas não
ck_ocorrfisaut_stsocmovfisaut (o nome da tabela não foi totalmente contemplado, pois a parte
movim foi retirada) e nem ck_oc_mov_fis_aut_sts_oc_mov_fis_aut (o caracter “ _ ” está
sendo usado como separador para o nome da entidade e do atributo)
Página 30
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
A determinação dos valores que um determinado atributo pode assumir deve ser feita da
seguinte forma:
[nome do atributo]
= [valor] and
>=
or
<=
<>
NOTAS:
Quando o [valor] for alfanumérico, colocá-lo entre aspas simples.
O Manual de Procedimentos Gerais de Sistemas relata algumas considerações sobre constraint
check.
Se existir um check em um campo que existe em mais de uma tabela, mas não é uma FK, o
nome da contraint deve ser alterado no script.
2.2.21.6. DEFAULT
Default é o valor padrão para um atributo a ser utilizado quando outros valores não forem
informados.
O padrão de nomenclatura para default é:
df_ttt...ttt_xxx...xxx
Onde:
 df é uma abreviatura de Default
 ttt...ttt indica o nome da entidade
 xxx...xxx indica o nome do atributo
Os nomes da entidade e do atributo podem ser abreviados, atentando sempre para contemplar
todas as “partes” que compõe os nomes dos mesmos.
O sublinhado ( _ ) deve existir somente para separar o nome da entidade do nome do atributo,
bem como para separar o nome da entidade do prefixo “df”. Ele não deve ser usado apenas
como separador de campo do nome da entidade ou do nome do atributo.
Exemplo:
Na
tabela
ocorrencia_movim_fisc_autom
existe
o
campo
dtc_ocorr_movim_fisc_autom, o qual possui um default de valor getdate(). O nome do
Default poderia ser df_ocmovfisaut_dtcocmovfisaut, mas não df_ocorrfisaut_stsocmovfisaut
(o nome da tabela não foi totalmente contemplado, pois a parte movim foi retirada) e nem
df_oc_mov_fis_aut_sts_oc_mov_fis_aut (o caracter “ _ ” está sendo usado como separador
para o nome da entidade e do atributo).
O Manual de Procedimentos Gerais de Sistemas relata algumas considerações sobre constraint
default.
Página 31
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
3. INDEPENDÊNCIA DE CODIFICAÇÃO
3.1. USO DE COMANDOS “SELECT *” E “INSERT *”
Não devem ser utilizados os comandos “select *” e “insert *” nem no código fonte das
aplicações, nem em triggers, procedures, funções, etc... para que se possa garantir a
independência da codificação. Dessa forma, minimiza-se aos impactos provocados seja por
inclusões de novos atributos ou por alteração da ordem dos campos de uma tabela.
3.2. REFERENCIAR ENTIDADES E ATRIBUTOS
Para garantir independência de codificação quanto aos impactos provocados pela inclusão de
entidades já existentes em outros bancos, ao referenciar entidades, o nome do banco deve
sempre ser utilizado internamente na codificação – seja em triggers, procedures, código fonte
da aplicação, funções, etc... Essa referência deve ser efetuada da seguinte forma:
nome_do_banco.nome_da_entidade.
Exemplo: bd_recursos_humanos.servidor.
Já no caso dos atributos, não só o nome do banco, mas também o nome da entidade deve
sempre ser utilizado internamente na codificação – seja em triggers, procedures, código fonte
da aplicação, funções... Isso porque pode ocorrer a inclusão de campos já existentes em outras
entidades. Essa referência deve ser efetuada da seguinte forma: nome do banco.nome da
entidade.nome do atributo.
Exemplo: bd_recursos_humanos.servidor.nom_servidor
Um atributo pode ser referenciado através de um Alias para uma entidade. Ver item
Entidades.
Exemplo: serv.nom_servidor (ver Exemplo do item Entidades).
NOTA:
Sugere-se criar um ALIAS para as entidades criadas, pois os mesmos podem ser referenciados
posteriormente em qualquer parte da consulta (query).
Exemplo: bd_recursos_humanos.servidor serv
4. PADRÃO DE LAYOUT DE TRIGGERS
4.1. CONSIDERAÇÕES GERAIS
Os triggers são implementados seja para garantir a integridade referencial entre tabelas de
bancos diferentes, seja para efetuar algum tratamento de negócio ou geração de auditoria ou
de históricos, entre outras coisas.
Página 32
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
NOTA:
O acesso a bancos de dados localizados em outros servidores somente deve ocorrer nos
triggers através de views de linked server ou de chamadas remotas a procedures. Para
conhecimento dos padrões e das orientações sobre o uso de views de linked server ou de
chamadas remotas a procedures, consultar o tópico 2.2.5.3. VIEWS DE LINKED SERVER.
Existem algumas precauções que devem ser tomadas ao se implementar um trigger. Seguem
algumas delas:

Quanto à utilização de cursores, pelo fato destes degradarem performance.
Só se deve utilizar cursor quando for necessário realizar algum tratamento
registro a registro e não for possível fazê-lo através de comandos DML que
afetem o bloco inteiro de registros.

Quanto à importância de tratamento de múltiplas linhas.
Em caso de atualização de múltiplas linhas em uma tabela, o trigger precisa
garantir que inconsistências não serão geradas e erros não serão mascarados.

Quanto ao tratamento de erro.
É obrigatória a utilização dos comandos RAISERROR, ROLLBACK e RETURN
nos triggers para garantir a exibição de mensagens e finalização correta da
transação em caso de erro.

Quanto à integridade referencial entre tabelas de servidores diferentes.
A única forma segura de garantir essa integridade é através do uso de linked
server, sendo proibido o acesso a tabelas replicadas.
Deve-se colocar comentários no corpo dos triggers, com o objetivo de identificar a data da
manutenção, o projeto solicitante, banco, tabela e campo envolvidos no tratamento da regra de
integridade (em triggers de integridade referencial), da regra de negócio (em triggers de
negócio) ou da regra de auditoria (em triggers de auditoria).
NOTA:
O documento de Boas Práticas, disponível no PRT, relata outras considerações importantes sobre
utilização de cursores, controle de transação, entre outras coisas aplicáveis aos triggers.
4.2. TRIGGERS SEM CURSOR
PADRAO DE ESTRUTURA PARA TRIGGERS SEM CURSOR:
Exemplo1:
/* ---------------------------- */
/* TRIGGER DE INSERT SEM CURSOR */
/* ---------------------------- */
Página 33
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
CREATE TRIGGER tg_ref_<nome_da_tabela>_ins ON <nome_da_tabela> FOR
INSERT
AS
/* Declaracao de variaveis */
DECLARE @<variavel1> ...
/* Estrutura padrão para integridade referencial */
IF ( SELECT count(1) FROM <tabela_pai> P, inserted
WHERE P.<chave_primaria> = inserted.<chave_estrangeira> ) <>
( SELECT count(1) FROM inserted )
BEGIN
RAISERROR ...
ROLLBACK TRANSACTION
RETURN
END
Exemplo2:
/* ---------------------------- */
/* TRIGGER DE DELETE SEM CURSOR */
/* ---------------------------- */
CREATE TRIGGER tg_ref_<nome_da_tabela>_del ON <nome_da_tabela> FOR
DELETE
AS
/* Declaracao de variaveis */
DECLARE @<variavel1> ...
/* Estrutura padrão para integridade referencial */
IF
( SELECT count(1) FROM <tabela_filho> F, deleted
WHERE
F.<chave_estrangeira> = deleted.<chave_primaria> ) > 0
BEGIN
RAISERROR ...
ROLLBACK TRANSACTION
RETURN
END
Exemplo3:
/* ---------------------------- */
/* TRIGGER DE UPDATE SEM CURSOR */
/* ---------------------------- */
CREATE TRIGGER tg_ref_<nome_da_tabela>_upd ON <nome_da_tabela> FOR
UPDATE
AS
/* Declaração de variaveis */
DECLARE @<variavel1> ...
Página 34
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
/* Estrutura padrão para integridade referencial */
IF UPDATE(<chave_estrangeira>)
BEGIN
IF ( SELECT count(1) FROM <tabela_pai> P, inserted
WHERE P.<chave_primaria> = inserted.<chave_estrangeira> )
<>
( SELECT count(1) FROM inserted )
BEGIN
RAISERROR ...
ROLLBACK TRANSACTION
RETURN
END
END
4.3. TRIGGERS COM CURSOR
PADRAO DE ESTRUTURA PARA TRIGGERS COM CURSOR:
Exemplo1:
/* ---------------------------- */
/* TRIGGER DE INSERT COM CURSOR */
/* ---------------------------- */
CREATE TRIGGER tg_neg_<nome_da_tabela>_ins ON <nome_da_tabela> FOR
INSERT
AS
/* Declaracao de variaveis */
DECLARE @<variavel1> ...
/* Cursor Padrão */
DECLARE crs_<nome_da_tabela>_ins CURSOR
FOR SELECT
inserted.<campo1>,
inserted.<campo2>,
...
FROM inserted
/* <campo1> é a chave da tabela */
OPEN crs_<nome_da_tabela>_ins
FETCH NEXT FROM crs_<nome_da_tabela>_ins
INTO @<campo1>_ins, @<campo2>_ins, ...
WHILE (@@FETCH_STATUS <> -1)
BEGIN
...
FETCH NEXT FROM crs_<nome_da_tabela>_ins
INTO @<campo1>_ins, @<campo2>_ins, ...
END
Página 35
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
CLOSE crs_<nome_da_tabela>_ins
DEALLOCATE crs_<nome_da_tabela>_ins
Exemplo2:
/* ---------------------------- */
/* TRIGGER DE DELETE COM CURSOR */
/* ---------------------------- */
CREATE TRIGGER tg_neg_<nome_da_tabela>_del ON <nome_da_tabela>
DELETE
AS
FOR
/* Declaracao de variaveis */
DECLARE @<variavel1> ...
/* Cursor Padrão */
DECLARE crs_<nome_da_tabela>_del CURSOR
FOR SELECT
deleted.<campo1>,
deleted.<campo2>,
...
FROM deleted
/* <campo1> é a chave da tabela */
OPEN crs_<nome_da_tabela>_del
FETCH NEXT FROM crs_<nome_da_tabela>_del
INTO @<campo1>_del, @<campo2>_del, ...
WHILE (@@FETCH_STATUS <> -1)
BEGIN
...
FETCH NEXT FROM crs_<nome_da_tabela>_del
INTO @<campo1>_del, @<campo2>_del, ...
END
CLOSE crs_<nome_da_tabela>_del
DEALLOCATE crs_<nome_da_tabela>_del
Exemplo3:
/* ---------------------------- */
/* TRIGGER DE UPDATE COM CURSOR */
/* ---------------------------- */
CREATE TRIGGER tg_neg_<nome_da_tabela>_upd ON <nome_da_tabela> FOR
UPDATE
Página 36
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
AS
/* Declaração de variaveis */
DECLARE @<variavel1> ...
/* Cursor Padrão */
DECLARE crs_<nome_da_tabela>_upd CURSOR
FOR SELECT
deleted.<campo1>,
inserted.<campo1>,
deleted.<campo2>,
inserted.<campo2>,
...
FROM deleted,inserted
WHERE deleted.<campo1> = inserted.<campo1>
/* <campo1> é a chave da tabela */
OPEN crs_<nome_da_tabela>_upd
FETCH NEXT FROM crs_<nome_da_tabela>_upd
INTO @<campo1>_del,
@<campo1>_ins,
...,
@<campo2>_del,
@<campo2>_ins,
...
WHILE (@@FETCH_STATUS <> -1)
BEGIN
...
FETCH NEXT FROM crs_<nome_da_tabela>_upd
INTO @<campo1>_del,
@<campo1>_ins,
...,
@<campo2>_del,
@<campo2>_ins,
...
END
CLOSE crs_<nome_da_tabela>_upd
DEALLOCATE crs_<nome_da_tabela>_upd
4.4. TRIGGERS INSTEAD OF INSERT
PADRÃO DE CÓDIGO PARA ASSEGURAR QUE UMA TABELA SÓ TENHA UMA
LINHA:
/* ------------------------- */
/* TRIGGER INSTEAD OF INSERT */
/* ------------------------- */
Página 37
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
CREATE
TRIGGER
INSTEAD OF INSERT
AS
29/05/2017
tg_neg_<nome_da_tabela>_ins
ON
<nome_da_tabela>
/* Se a tabela já possuir alguma linha ou se a quantidade de linhas
sendo inseridas for maior do que um, retorna-se com erro. */
IF
(SELECT count(1) FROM <nome_da_tabela>) > 0
OR
(SELECT count(1) FROM inserted) > 1
BEGIN
RAISERROR ...
ROLLBACK TRANSACTION
RETURN
END
ELSE
/* Efetua na tabela a inserção, que havia sido impedida pelo
trigger, da linha existente em “inserted”. */
INSERT INTO <nome_da_tabela>
(<nome_campo_1>, <nome_campo_2>, ..., <nome_campo_n>)
SELECT <nome_campo_1>, <nome_campo_2>, ..., <nome_campo_n>
FROM inserted
4.5. TRIGGERS DE AUDITORIA
O padrão de preenchimento de tabelas de auditoria, referente às atualizações realizadas
através de aplicações que não usam UniFW (Ex.: atualização da tabela
fechamento_arrecadacao através do Query Analyzer), exige que os triggers de auditoria
dessas tabelas sigam os direcionamentos abaixo:

Deve-se preencher os campos da tabela OperacaoAuditoria da seguinte forma:
1) Campo Interface: com uma string contendo o código ASA do projeto (ou
módulo) responsável pela tabela;
2) Campo SiglaDominioUsuario: com a string "SEFAZ", o mesmo padrão utilizado
pelas aplicações UniFw;
3) Campo Funcao: com "Inserção/Alteração/Exclusão de <nome_da_tabela>";
4) Campo EnderecoRemoto: com o valor da função HOST_NAME().

Já o preenchimento dos campos referentes às informações do usuário que executou a
operação deve considerar as seguintes possibilidades:
1) O login utilizado é o cda ou o cda_aplic (aplicações cliente/servidor, padrão
SEFAZ):
Deve-se capturar o login através da função APP_NAME(), observando as seguintes
situações:
a) Se o valor retornado pela função APP_NAME() for NULL (relatórios do
Crystal, aplicações fora de padrão, etc), utilizar o valor retornado pela função
Página 38
841071913
Secretaria da Fazenda do Estado da Bahia
DTI - Diretoria de Tecnologia da Informação
29/05/2017
USER_NAME(), ou seja, cda ou cda_aplic e na descrição do usuário
"Usuário não Identificado";
b) Se o valor retornado pela função APP_NAME() for diferente de NULL,
verificar se está no padrão SEFAZ (APLICAÇÃO/login), ou seja, se existe
uma “/” (barra). Em caso afirmativo, capturar o conteúdo que está logo após a
barra e considerar como o LOGIN. A descrição do usuário deverá ser obtida
na tabela de servidor ou na tabela de terceiro e, caso não exista, deve ser
preenchida com "Usuário não Identificado".
2) O login utilizado é o cda_web (aplicações web, não .Net):
Por enquanto, as aplicações web não informam o nome do usuário, logo, deve-se
registrar o login como cda_web, e a descrição do usuário como "Usuário não
Identificado".
3) O login utilizado é o usr_sefinfra (DSCAD):
Por enquanto, as aplicações COM+ não informam o nome do usuário, logo, deve-se
registrar o login como usr_sefinfra, e a descrição do usuário como "Usuário não
Identificado".
4) O login utilizado não é um login de aplicação (acesso direto via Query Analyzer,
VB, Access, etc):
O login deve ser capturado através da função USER_NAME(). A descrição do
usuário deverá ser obtida na tabela de servidor ou na tabela de terceiro e, caso não
exista, deve ser preenchida com "Usuário não Identificado".
Página 39
841071913