proposta de consultoria em gestão de dados e sistemas · a ausência de padronização no...

Norma de Administração de dados e Objetos de Banco de Dados

Rio de Janeiro, 01 de Novembro de 2013

Padrão de Nomenclatura - Objetos de Banco de Dados

2/19

Histórico de versões

Número Modificação Data Responsável

1.0 Criação do documento 05/11/2012 Roberta Berrondo

1.1 Criação de padrão para nome de constraint, novo

classificador de coluna para tabela, objetos descontinuados

e descrição de objetos

30/01/2013 Andre Oliveira

1.2 Normas para modelagem de banco de dados, boas práticas

para desenvolvimento de queries e inclusão de descrição da

coluna

01/11/2013 Andre Oliveira


3/19

Sumário

Padrão de objetos de Banco de Dados .......................................................................................................... 4

1. Regras de Nomenclatura........................................................................................................................... 4

1.1. Entidades e Tabelas ....................................................................................................................................... 4

a) Prefixo de Tabelas .............................................................................................................................................. 5

b) Formação do Nome ............................................................................................................................................ 5

c) Dicionário de Dados - Documento em anexo .................................................................................................... 6

1.2. Atributos e colunas ....................................................................................................................................... 6

1.3. Formação do Nome ....................................................................................................................................... 8

1.4. Descrição de objetos (Stored procedures, Functions, Views e Triggers) ...................................................... 9

1.5. Views ............................................................................................................................................................. 9

1.6. Outros objetos............................................................................................................................................. 10

1.7. Procedimentos armazenados (Stored procedure, Function e Trigger) ....................................................... 12

1.8. Nomenclatura de objetos descontinuados ................................................................................................. 13

2. Colunas para controle de dados ............................................................................................................. 13

2.1. CDA_CONTROLE_ATIVO .............................................................................................................................. 13

2.2. CDA_CONTROLE_ORIGEM .......................................................................................................................... 14

2.3. CDA_CONTROLE_USO ................................................................................................................................. 14

2.4. DAT_CONTROLE_ALTERACAO ..................................................................................................................... 14

3. Procedimentos para elaboração de modelo de dados e queries ........................................................... 14

3.1. Modelagem - Banco de Dados ................................................................................................................... 14

3.2. Elaboração de Queries ................................................................................................................................ 15

4. Carga de dados e objetos ........................................................................................................................ 18

5. Controle de Acesso e privilégios ............................................................................................................. 18


4/19

Padrão de objetos de Banco de Dados

O presente documento foi gerado pela necessidade de se ter um instrumento que oriente, normatize e padronize o desenvolvimento de aplicativos, facilitando a manutenção e a integração dos mesmos, reduzindo a redundância dos dados, permitindo uma documentação de forma centralizada e propiciando um entendimento comum entre os aplicativos através da definição de padrões.

A ausência de padronização no desenvolvimento de aplicações contribui para uma dificuldade de manutenção, demora no repasse e recebimento dos aplicativos, desorganização nos códigos e diretórios, duplicação de informações e consequente redução na produtividade.

Com a criação dessas Normas e Padrões, estaremos eliminando ou reduzindo essa deficiência e contribuindo de forma considerável para o início da Administração de Dados que permite um planejamento global dos dados, proporcionando o fim de aplicações isoladas e a proliferação de dados incompatíveis e redundantes.

Sendo assim, encontraremos os dados com uma maior disponibilidade, facilidade de interpretação, atualidade e exatidão, além de uma diminuição no seu custo, à medida que aumentaremos sua utilização compartilhada.

As Normas e Padrões contribuem também para a rapidez na resolução de problemas, facilidade de entendimento e conhecimento dos aplicativos, e melhoria na qualidade dos produtos e serviços prestados.

1. Regras de Nomenclatura

A seguir são exibidas as regras de nomenclatura para objetos do Banco de Dados

1.1. Entidades e Tabelas

O nome das tabelas deverá obedecer a seguinte regra de formação:

Nome: Prefixo_Nome1_NomeN Onde: Prefixo – define o tipo de tabela (ver item 1.1)

Nome1 ...NomeN – obedece às restrições de formação definidas no item 1.2

Exemplo:

TB_PESSOA, TB_PESSOA_INMETRO


5/19

a) Prefixo de Tabelas

Define o tipo a que se destina a tabela conforme quadro a seguir:

Prefixo Descrição

TB Tabela Padrão - Utilizada para armazenamento padrão. TB_ORCAMENTO TB_PESSOA_INMETRO

TL Tabela de LOG - Utilizada especialmente para auditoria (Trace). TL_ACESSO_SISTEMA

TH

Tabela de Histórico - Utilizada para armazenar histórico. Por exemplo, atualmente temos um job que exporta, dados da tabela Fale conosco que está no servidor RWEB02 para o servidor RSAC01S, este job em seu ultimo passo, apaga os dados da tabela Origem. Podemos ter a tabela TH_FALE_CONOSCO com a finalidade de armazenar estes dados no lugar de apagá-los. TH _AVALIADOR_CLASSE_ENSAIO TH_CATEGORIA_AVALIADOR

TR Tabela de Relacionamento (Relacionamento N:N) - Utilizada quando a tabela for predominantemente relacional. TR_CURSO_DISCIPLINA TR_PEDIDO_ITEM

TT Tabela TEMPORÁRIA – Utilizada para dados temporários. TT_CALCULA_PROVENTO TT_EMITE_RELATORIO TT_RELATORIO_OCORRENCIA_ABONO

TI Tabela Imagem - Destinada exclusivamente ao armazenamento de Imagens. Facilitando a manutenção, a tabela original onde as imagens estariam relacionadas possui um ponteiro que aponta para a tabela exclusiva de imagens. Esta tabela possui apenas dois atributos: IDT_IMAGEM, que seria o identificador único da tabela e o atributo OBJ_IMAGEM que armazenará as imagens propriamente ditas. TI_PRODUTOS

b) Formação do Nome

A formação do nome das tabelas deverá seguir as seguintes regras: • Utilizar nomes no singular e letras MAIÚSCULAS

• Utilizar como separador de palavras o caractere “_” (undescore)

• Tabelas de relacionamento devem iniciar com o nome da tabela dominante (ou mais forte).

• Escrever o nome por extenso quando possível

• Não utilizar acentos ou caracteres especiais.

• Utilizar substantivos/adjetivos qualificadores como por exemplo, TB_ATESTADO.

• A descrição deve ser o mais objetiva possível.

• O nome completo (inclui siglas, sequenciais e undescores) deverá ter preferencialmente o máximo de 60 Caracteres.


6/19

Obs.: Caso o nome ultrapasse os 60 caracteres, abreviar os nomes partindo do menos determinante até o mais importante desde que continue sendo possível o entendimento do nome da tabela.

c) Dicionário de Dados - Documento em anexo

Itens que devem estar documentados no Dicionário de Dados: • Descrição

• Tipo de dado

• Valor default (Devem ser claramente descritos Exemplo: Data de atualização = Getdate)

• Opção de nulidade

• Domínio (CDN_STATUS -> 1 = Aguardando, 2 = Concluído CDA_SEXO - > F = Feminino, M= Masculino)

1.2. Atributos e colunas

O nome das colunas deverá obedecer a seguinte regra de formação: Nome: Classificador_Nome1_NomeN Onde: Classificador – define o tipo de coluna (ver item 2.1) Nome1 ...NomeN – obedece às restrições de formação definidas no item 2.2. Caso o atributo não se encaixe em nenhuma categoria pré-determinada não será utilizado o classificador. No Caso de chave estrangeira, a tabela destino (Filha) herdará os atributos com os mesmo nome que já possuir na tabela de origem.

Cada coluna criada ou alterada deverá possuir uma descrição informando o propósito da mesma. Por exemplo: COLUNA DES_COMPLEMENTO_LOGRADOURO: Complemento. Por exemplo, apartamento 101, bloco 2, casa 3...


7/19

COMANDO NO SQL SERVER 2000

comando de inclusão use nomedobanco exec sp_addextendedproperty N'MS_Description', N'SELECAO AUTOMATICA.', N'user', N'dbo', N'table', N'certificado', N'column', N'ind_solicitacao_automatica'

comando de alteração use nomedobanco exec sp_updateextendedproperty N'MS_Description', N'SIGLA DO USUARIO.', N'user', N'dbo', N'table', N'idioma', N'column', N'sig_usuario'

COMANDO NO SQL SERVER 2008

comando de inclusão use nomedobanco EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'Complemento. Por exemplo, apartamento 101, bloco 2, casa 3...' , @level0type=N'SCHEMA',@level0name=N'SIGRH', @level1type=N'TABLE',@level1name=N'TB_PESSOA_FISICA_ENDERECO', @level2type=N'COLUMN',@level2name=N'DES_COMPLEMENTO_LOGRADOURO' GO

comando de alteração use nomedobanco EXEC sys.sp_updateextendedproperty @name=N'MS_Description', @value=N'Complemento. Por exemplo, apartamento 101, bloco 2, casa 3...' , @level0type=N'SCHEMA',@level0name=N'SIGRH', @level1type=N'TABLE',@level1name=N'TB_PESSOA_FISICA_ENDERECO', @level2type=N'COLUMN',@level2name=N'DES_COMPLEMENTO_LOGRADOURO' GO

a) Classificador - O quadro abaixo apresenta os tipos de classificadores para cada caso

Classificador Descrição Utilização Tipo SQL Observações

BLN Boolean Indicativo de dado Booleano BLN_STATUS_USUARIO

(Falso, Verdadeiro) (sim, Não) (0,1) (True, False)

Bit

CDA

Código Alfanumérico CDA_UO CDA_VOO

Identificação Alfanumérica

NChar<= 5 ou CHAR <=5 NVarchar >5 ou VARCHAR>5

CDN Código Numérico CDN_MATRICULA_SIAPE

Identificação Numerica Tinyint, Smallint, int, bigint

DES

Descrição DES_PRODUTO DES_CARGO

Texto Livre NChar<= 5 ou CHAR <=5 NVarchar >5 ou VARCHAR>5

DAT Data Informações apenas de Smalldatetime , Ex: 2001206 para


8/19

OBS: Quando o tipo de dados for uma String de tamanho fixo, sempre se deve utilizar CHAR ou NCHAR.

* O tipo de dados NVARCHAR ou NCHAR armazenam os dados em Unicode e utilizam 2 bytes ou 16 bits para representar um caractere. Deve utilizá-lo quando precisar armazenar caracteres de idiomas que exigem mais de um byte para representar um caractere.

1.3. Formação do Nome

A formação do nome das colunas deverá seguir as seguintes regras: • Utilizar nomes no singular

• Utilizar letras MAIÚSCULAS

• Utilizar como separador de palavras o caractere “_” (undescore)

DAT_NASCIMENTO DAT_VENCIMENTO_CONTRATO

Data e hora.

DateTime, Date (A PARTIR 2008), ou char ( nos casos parte de data)

os casos char.

HOR

Hora HOR_REGISTRO_OBJETO_SISTEMA HOR_EXCLUSAO_OBJETO

Informações de hora Time (A PARTIR 2008)

IDT

Identificação IDT_CONTRATO IDT_PESSOA_INMETRO

Identificação numérica Tinnyint, Smallint, int, bigint Deve ser utilizado para sequenciais internos sendo ou não identity

NOM

Nome NOM_SERVIDOR NOM_PRODUTO

Nome de pessoas, lugares, objetos

NVarchar

NUM

Número NUM_TELEFONE NUM_MATRICULA_SIAPE

Identificação numérica Tinnyint, Smallint, int, bigint

OBJ

Objeto OBJ_FOTO_PRODUTO_TESTADO OBJ_RELATORIO_TECNICO

Qualquer tipo de arquivo (documentos Word/Excel, arquivos de imagens, arquivos de som, arquivos texto, etc...)

Image, Text ( apenas para o sqlserver 2000) Ntext,Filestream, CLOB,XML

QTD Quantidade QTD_DIAS_ATENDIMENTO

Informação numérica indicativa de quantidade

Tinnyint, Smallint, int, bigint

SIG Sigla SIG_ORGAO SIG_UF

Informação textual resumida.

CHAR <=5 ou *NChar<= 5 VARCHAR>5 ou *NVarchar > 5

TIP Tipo TIP_ATENDIMENTO_SESAO TIP_CONTRATO_SERVICO

Domínio definido e finito

CHAR <=5 ou *NChar<= 5 VARCHAR>5 ou *NVarchar >5

VAL Valor VAL_UNITARIO_MAO_OBRA VAL_BOLSA

Moedas e índices

Numeric(x,y)


9/19

• Escrever o nome por extenso

• Não utilizar acentos ou caracteres especiais.

• Utilizar substantivos/adjetivos qualificadores

• A descrição deve ser o mais objetiva possível.

• O nome completo (inclui siglas, sequenciais e undescores) deverá ter preferencialmente o máximo de 40 caracteres.

Obs: Caso o nome ultrapasse os 30 caracteres, abreviar os nomes partindo do menos determinante até o mais importante desde que continue sendo possível o entendimento do nome da coluna.

1.4. Descrição de objetos (Stored procedures, Functions, Views e Triggers)

A descrição do objeto haverá o seguinte formato no seu cabeçalho: /* [Descrição do Objeto] -- [Data da criação] [Analista responsável pela criação] [ Breve descrição negocial do objeto] -- [Data da alteração1] [Analista responsável pela alteração1] [motivo alteração1] -- [Data da alteração n] [Analista responsável pela alteração n] [motivo alteração n] */

Todos os blocos de programação que atenda uma regra de negócio contido no objeto deverão conter comentários explicativos sobre o seu procedimento.

Ex:

/* [Descrição do bloco] – Clientes que realizaram o pagamento no anterior */ If (@BLN_CLIENTE = 1 and @DT_PG < Gatdate()) Begin Insert into Imposto_Pago select

tb0.num_processo as codigo,

tb0.nuproc as processo,

Razao_Social,

convert(varchar(10),tb0.dasolicita,103) as data_solcitacao

from

Tabela_1 tb0

where

tb0.cotiposerv in (11,12) and

and not exists (select 1 from credenciamento.dbo.solicitacao tb1

where tb0.num_processo = tb1.num_processo)

end

1.5. Views

O nome das views deverá obedecer a seguinte regra de formação: Nome = VW_Nome1_NomeN Onde: VW é o prefixo para views


10/19

Nome obedece às mesmas restrições de formação definidas para entidades/tabelas (ver item 1.2) e deve sugerir a finalidade da View. O objeto deverá conter a descrição de objeto (ver item 1.4) Por exemplo: VW_SERVIDOR_LOTACAO VW_CONTRATO_UO

1.6. Outros objetos

a) Índices

O nome do índice deve ter preferencialmente no máximo 60 caracteres, obedecendo à restrição de formação descrita no item 1.2 (para abreviações, principalmente). A regra de formação será: IX_NOME_TABELA_Nr Onde: Nr é um número sequencial. IX é o prefixo pré-determinado para índices Por exemplo: IX_PESSOA_1 IX_PESSOA_INMETRO_4 Caso se trate de um índice único, a regra de formação será: IX_UNIQUE_NOME_TABELA_COLUNA Por exemplo: IX_UK_TB_PESSOA_FISICA_NUM_PIS_PASEP IX_UK_TB_PESSOA_FISICA_NUM_CNH

b) Primary Key (PK)

O nome da PK deve ter preferencialmente no máximo 60 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.). A regra de formação será: PK_NOME_DA_TABELA Onde: PK é o prefixo predeterminado para Primary Key Por exemplo: PK_PESSOA_INMETRO

c) Foreing Key (FK)


11/19

O nome da FK deve ter preferencialmente no máximo 80 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.). A regra de formação será: FK_NOME_DA_TABELA_filho_NOME_DA_TABELA_pai Onde: FK é o prefixo predeterminado para Foreign Key

Por exemplo:

FK_ATESTADO_LOCAL_ENTREGA

Dicas: • Caso exista mais de uma FK entre duas tabelas, colocar um nome significativo para o relacionamento no final. Por exemplo: FK_ORGAO_PROCESSO_ORIGEM, FK_ORGAO_PROCESSO_DESTINO

d) Unique Key (UK)

O nome da UK deve ter preferencialmente no máximo 80 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.). A regra de formação será: UK_NOME_DA_TABELA_NOME_DO_CAMPO Onde: UK é o prefixo predeterminado para Unique Key Por exemplo: UK _ORGAO_COD_ORGAO: significa uma unique key na tabela TB_ORGAO no campo COD_ORGAO.

e) Constraint (CK)

O nome da CK deve ter preferencialmente no máximo 80 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.). A regra de formação será: CK_NOME_DA_TABELA_NOME_DO_CAMPO Onde: CK é o prefixo predeterminado para Constraint Por exemplo: CK_TB_LOCAL_INSPECAO_TIP_PESSOA: significa uma constraint na tabela TB_LOCAL_INSPECAO no campo TIP_PESSOA.


12/19

1.7. Procedimentos armazenados (Stored procedure, Function e Trigger)

a) Stored Procedure

O tamanho máximo para o nome de uma procedure é preferencialmente de 80 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.).

O objeto deverá conter a descrição de objeto (ver item 1.4) A regra de formação será: PU_NOME_RESUMIDO_PROGRAMA Onde: PU (Procedure de Usuário) é o Prefixo padrão para Stored Procedures.

Por exemplo: PU_ CALC_DAT_IMPUGNACAO

b) Function

O tamanho máximo para o nome de uma procedure é preferencialmente de 80 caracteres, obedecendo à restrição de formação descrita no item 1.2 (letras maiúsculas, abreviações etc.).

O objeto deverá conter a descrição de objeto (ver item 1.4) A regra de formação será: FU_ NOME_RESUMIDO_FUNCAO Onde: FU (Função de Usuário) é o Prefixo padrão para Functions. Por exemplo: FU_ENTRADA_ITEM

c) Trigger

O Tamanho máximo para o nome de uma trigger é preferencialmente de 80 caracteres, obedecendo à restrição de formação descrita no item 1.2( letras maiúsculas, abreviações etc.).

O objeto deverá conter a descrição de objeto (ver item 1.4) A regra de formação será: TG_NOME_RESUMIDO_TRIGGER Onde: TG é o prefixo padrão para Triggers. Por exemplo: TG_PRODUTO_ADICIONADO

c.1) Trigger de auditoria

Utilizada para realizar auditorias (Trace). O objeto deverá conter a descrição de objeto (ver item 1.4)

A regra de formação será: TG_AUD_NOME_RESUMIDO_TRIGGER Onde: TG_AUD é o prefixo padrão para triggers de auditorias. Por exemplo:


13/19

TG_AUD_FALE_CONOSCO

(c.2) Trigger de Foreing Key

Utilizada para simular Foreing Key entre Databases diferentes. A regra de formação será: TG_FK_NOMEORIGEM_NOMEDESTINO Onde: TG_FK é o prefixo padrão para triggers de auditorias. Por exemplo: TG_FK_SAC_GEAD

1.8. Nomenclatura de objetos descontinuados

a) Objetos em geral

Quando um objeto da base de dados for descontinuado, seja procedure, tabela ou de qualquer outro tipo, seu nome deverá ser alterado para que seja possível identifica-lo visualmente. Deve ser colocado “--- Apagar aaaa-mm-dd” após o nome do objeto, onde “aaaa-mm-dd” é a data em que o objeto foi colocado em quarentena (Renomeado). O período de quarentena deverá ser de noventa (90) dias corrido e após esta data deverá ser excluído fisicamente do banco de dados. Por exemplo: PU_ CALC_DAT_IMPUGNACAO ---Apagar 2012-11-25

2. Colunas para controle de dados

A seguir são exibidas as colunas utilizadas para controle das informações de uma base. Todas as tabelas devem possuir estas colunas.

2.1. CDA_CONTROLE_ATIVO

Do tipo char, com comprimento 2 [char(2)]. Guarda o status atual da informação contida na linha. Onde a linha pode estar ativa “A” ou desativada “D”. Caso a linha esteja desativada, significa que a mesma foi deletada logicamente, portanto não deve ser considerada. O domínio de dados desta coluna reside na tabela TB_CONTROLE_ATIVO.


14/19

2.2. CDA_CONTROLE_ORIGEM

Do tipo char, com comprimento 2 [char(2)]. Guarda a origem da informação contida na linha. Esta informação pode ter sido incluída por um sistema do próprio Inmetro “I” ou por outras fontes de dados, como o SIAPE “S”, por exemplo. O conjunto de valores para esta coluna pode variar de acordo com a base e sistema aos quais o dado pertence. O domínio de dados desta coluna reside na tabela TB_CONTROLE_ORIGEM.

2.3. CDA_CONTROLE_USO

Do tipo char, com comprimento 2 [char(2)]. Informa se a informação contida na linha é utilizada pelo Inmetro “I” ou por outras instituições “O”. O conjunto de valores para esta coluna pode variar de acordo com a base e sistema aos quais o dado pertence.

O domínio de dados desta coluna reside na tabela TB_CONTROLE_USO.

2.4. DAT_CONTROLE_ALTERACAO

Do tipo data e hora [datetime]. Armazena a data e hora que a informação na linha foi alterada pela última vez, independente da coluna ou colunas alteradas.

3. Procedimentos para elaboração de modelo de dados e queries

3.1. Modelagem - Banco de Dados

Este é um dos aspectos mais críticos para a criação de aplicações que tenham um desempenho adequado de Banco de Dados. Um sistema de dados com a performance adequada passa pelo desenho adequado de sua estrutura. Um modelo de dados deve possuir: 3.1.1. Ser representado de forma clara e objetiva, traduzindo todas as informações importantes pertinentes ao negócio. 3.1.2. Possuir reaproveitamento de informações contidas em outros esquemas e modelos a fim de garantir um modelo CORPORATIVO, evitando ao máximo a redundância de dados garantindo desta forma à qualidade da informação. 3.1.3. Possuir representações consistentes com facilidade de manutenção de dados. Excessos de informações não trarão melhores resultados e sim tornará o modelo obsoleto com dificuldade de eleição de dados realmente relevantes aos sistemas.


15/19

3.1.4. Representar o mundo real de forma correta e confiável. Os dados devem ter sua origem bem definida e estar representado de forma consistente. Informações do mesmo tipo devem ser representadas da mesma forma. 3.1.5. O modelo obrigatoriamente deve estar completamente documentado. A finalidade de cada objeto deve estar definida com clareza de forma inequívoca a fim de garantir sua fácil compreensão e manutenção, diminuindo o tempo em manutenção e evitando retrabalhos.

3.2. Elaboração de Queries

Através do estudo do desempenho e otimização de consultas SQL, procura-se a minimização do tempo de resposta do servidor de banco de dados. Essa minimização influencia na produtividade de trabalho coletivo à medida que não degrada o desempenho operacional dos sistemas. Para que o banco de dados apresente um bom desempenho é preciso partir do pressuposto da existência de uma boa estrutura de banco de dados, adequadamente normalizada e que possua índices úteis. Além disso, é preciso escrever consultas de forma otimizada. No entanto, deve-se enfatizar a importância de se conhecer como o otimizador de consultas funciona para melhor formular uma consulta ou para entender quais índices podem ser criados. Deve-se escrever as consultas da maneira mais intuitiva e tentar otimizá-las apenas se seu desempenho não parecer suficientemente bom (SOUKUP & DELANEY, 1999). Partindo desse principio as queries devem atender as seguintes requisições: 3.2.1. Reduza o volume de dados transmitidos na rede selecionando bem as colunas e linhas realmente necessárias através do comando SELECT, tentando selecionar pequenos conjuntos de dados. Não utilize SELECT * e evite SELECT sem cláusula WHERE.

Por exemplo: SELECT nome_coluna1, nome_coluna2, nome_coluna3 FROM TB_NOME_TABELA WHERE nome_coluna2 IS NOT NULL

3.2.2. Limite o número de tabelas sendo acessadas no join. Joins com mais de 6 tabelas só devem ser implementados após analisados junto com a equipe de AD. 3.2.3. Colunas de tabelas diferentes sendo comparadas em join devem ser NOT NULL e ter mesmo tipo, tamanho e precisão, para permitir o uso dos índices existentes (devem ser definidos índices adequados em cada tabela para atender o join). 3.2.4. Para diminuir o custo do join, tente colocar o maior número de condições possível no WHERE para selecionar bem as linhas de cada tabela sendo acessada, mesmo que algumas condições sejam redundantes. 3.2.5. Prefira o uso de join ao invés de sub-query, sempre que possível, pois sua execução é em geral mais eficiente. Por exemplo:


16/19

Solução menos eficiente:

SELECT (SELECT TAB2.nome_coluna FROM TB_NOME_TABELA2 AS TAB2 WHERE TAB2. nome_coluna = TAB1. nome_coluna1 ) AS nome_coluna1, TAB1.nome_coluna2, TAB1.nome_coluna3 FROM TB_NOME_TABELA AS TAB1 WHERE

nome_coluna2 IN (‘AG’, ‘CF’, ‘GH’)

Solução mais eficiente:

SELECT TAB1.nome_coluna1, TAB1.nome_coluna2, TAB1.nome_coluna3 FROM TB_NOME_TABELA AS TAB1 LEFT JOIN TB_NOME_TABELA2 AS TAB2 WHERE TAB2 ON TAB1.nome_coluna1 = TAB2. nome_coluna1 WHERE

TAB1.nome_coluna2 IN (‘AG’, ‘CF’, ‘GH’)

3.2.6. Utilizar a clausula EXISTS numa consulta ao invés da clausula IN, nos casos em que a sub-consulta é utilizada, pois a o consulta se torna mais eficiente.

Por exemplo:

Indicação para o uso do IN:

SELECT nome_coluna1, nome_coluna2, nome_coluna3 FROM TB_NOME_TABELA

WHERE nome_coluna2 IN (‘AG’, ‘CF’, ‘GH’)

Indicação para o uso do EXISTS:

SELECT TAB1.nome_coluna1, TAB1.nome_coluna2, TAB1.nome_coluna3

FROM TB_NOME_TABELA AS TAB1

WHERE EXISTS (SELECT 1 FROM TB_NOME_TABELA2 AS TAB2 WHERE TAB2.nome_coluna1 =

TAB1.nome_coluna1)


17/19

3.2.7. O uso de EXISTS e IN são mais eficientes que NOT EXISTS e NOT IN. Por exemplo:

Solução menos eficiente:

if not exists ( select a from t where a = 3 ) begin grupo 1 end else begin grupo2 end

Solução mais eficiente:

if exists ( select a from t where a =3 ) begin grupo 2 end else begin grupo 1 end

3.2.8. Não utilize o comando NOLOCK, ao invés disso, utilize o comando:

Por exemplo:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITED; SELECT nome_coluna1, nome_coluna2, nome_coluna3 FROM TB_NOME_TABELA

3.2.9. As seguintes operações devem ser usadas com cuidado, pois tornam as queries custosas por prejudicar o uso de índices ou usar tabelas temporárias:

NOT ou <>;

Ausência de cláusula WHERE ou WHERE pouco seletivo;

Funções de agregação de linhas (exs: SUM, AVG);

Expressões, conversões de dados ou manipulação de strings, principalmente na cláusula

WHERE;

Variáveis locais no WHERE (exceção: parâmetro de entrada de stored procedures com

mesmo tipo/tamanho da coluna Sql com a qual é comparado);


18/19

Distinct ou Union;

Like com String de comparação iniciado por % ou _;

Comparação entre colunas da mesma tabela;

3.2.10. As seguintes operações devem ser evitadas pois não serão mais aceitas em versões futuras do Sql Server 2000:

!= (usar <>)

*= (usar RIGHT OUTER JOIN)

=* (usar LEFT OUTER JOIN)

" para delimitar constantes alfanuméricas (usar ' )

4. Carga de dados e objetos

4.1. Ambiente de Desenvolvimento

A carga de dados e objetos será realizada no ambiente de desenvolvido sob demanda.

4.2. Ambiente de Homologação

A carga de dados e objetos no ambiente de homologação será realizada de forma periódica.

5. Controle de Acesso e privilégios

5.1. Ambiente de Desenvolvimento

No ambiente de desenvolvimento serão permitidas as manutenções de dados e comandos DDL apenas por

usuários devidamente autorizados.

5.2. Ambiente de Homologação


19/19

No ambiente de homologação serão permitidas manutenções de dados apenas por usuários de aplicação e

devidamente autorizados.

5.3. Ambiente de Produção

No ambiente de produção serão permitidas manutenções de dados apenas por usuários de aplicação.

proposta de consultoria em gestão de dados e sistemas · a ausência de padronização no...

Documents