Apresentação - Coord

Projeto Integridade Referencial
Versão AP 8.11
Emerson Tobar
Adm Bancos de Dados
• Normalização
• Objetivo e Conceito da Implementação
• Estrutura de Relacionamento
• Solução Proposta
• Vantagens e Desvantagens
• Tarefas - Desenvolvimento
• Normalização
– Definir a estrutura de entidades e seus
atributos eliminando vários problemas de
definição de armazenamento dos dados.
• ( Desenho Lógico )
– Evitar a repetição de informação e
desperdício de espaço
– Cinco níveis de normalização, porém utiliza-
se apenas até o 3° nível.
• 1a. Forma
– Definição da entidade, seus atributos e uma
chave de identificação
• 2a. Forma
– Separação em outra tabela dos atributos que
dependem da chave e que se se repetem
• Endereços, Itens de Pedido
• 3a. Forma
– Separação dos atributos que dependem de
outros atributos que não são chaves
• Estado e descrição do Estado
– Eliminar atributos que dependam de outros

atributos da mesma linha
• Valor Total, Quantidade Total, etc.
• Existem outras duas regras de
normalização (4a. e 5a. Forma), porém se
têm conhecimento de sua utilização
apenas na base de dados do Conselho
Jedi, implantado pelo Mestre Yoda e
Obi-Wan Kenobi.
• Objetivo
– Permitir que os clientes usuários do AP8
possam utilizar “opcionalmente” a integridade
referencial no Banco de Dados
• Conceito e Implementação
– Criar relacionamento entre entidades,
utilizando chave única (R_E_C_N_O_).
– O relacionamento será feito através de trigger
e stored procedures
Bancos Suportados
• Estrutura de Relacionamento
– TabelaA - Cadastro (origem da informação)
• PrimaryKey – PK_TabelaA
– TabelaB – Movimentação dependente do
dado gravado em TabelaA
• Foreign Key que aponta para TabelaA
• Solução Proposta
– Criação de tabela auxiliar com
relacionamento 1 para 1 com a tabela
ContraDomínio e N para 1 para as tabelas
Domínio.
• SE5010 -> SE5010FK -> SA1010FK ->SA1010
– Para construção deste relacionamento
utilizaremos as informações cadastradas na
tabela SX9.
SE5010 SE5010FK SA1010FK SA1010
PK R_E_C_N_O_ FK6 ID PK,FK1 ID PK R_E_C_N_O_
E5_BANCO FK3 ID_SA6 A1_COD

E5_AGENCIA FK1 ID_SA1 A1_LOJA
E5_CONTA FK2 ID_SA2 D_E_L_E_T_
E5_PREFIXO FK4 ID_SE1
E5_NUMERO FK5 ID_SE2
E5_PARCELA R_E_C_N_O_ SA2010FK SA2010
E5_CLIFOR
E5_LOJA PK,FK1 ID PK R_E_C_N_O_
E5_RECPAG
E5_TIPODOC A2_COD
E5_TIPO A2_LOJA
D_E_L_E_T_ D_E_L_E_T_
SE1010FK SE2010FK
SA6010FK SA6010
PK,FK3 ID PK,FK3 ID
PK,FK1 ID PK R_E_C_N_O_
FK1 ID_SA1 FK1 ID_SA1
FK2 ID_SA2 FK2 ID_SA2 A6_COD
A6_AGENCIA
A6_NUMCON
D_E_L_E_T_
SE1010 SE2010
PK R_E_C_N_O_ PK R_E_C_N_O_
E1_PREFIXO E2_PREFIXO
E1_NUM E2_NUM
E1_PARCELA E2_PARCELA
E1_CLIENTE E2_FORNECE
E1_LOJA E2_LOJA
D_E_L_E_T_ D_E_L_E_T_
• Vantagens
– Garantir a integridade dos dados
armazenados em uma base.
• Reduzir a possibilidade de existir filhos sem pai
• Para incluir um filho é necessário a existência do
pai
• Para excluir um pai, não podem existir filhos
– Ganho de performance ao fazer join

utilizando a tabela de relacionamento.
• Desvantagens
– Perda de performance em operações de
insert e update.
– Redução da facilidade de manipulação da
base
• Tarefas – Desenvolvimento
– Tabela SX3
• Campo X3_CONDSQL – indica se o campo possui
dependência de outros no seu preenchimento
– Ex. Banco, Agência e Conta / Prefixo, Número e Parcela
• Campo X3_CHKSQL – indica condição de
preenchimento do campo.
– Ex XY_SALARIO > 0, XY_NOME <> ‘ ‘
• Tarefas – Desenvolvimento
– Tabela SX9
• Cadastramento dos relacionamentos
• Campo X9_CONDSQL – indica a validação de
preenchimento para os campos com conteúdo
duplo ( E5_CLIFOR, D2_CLIENTE, E1_CLIENTE )
– Ex. Condição para preenchimento de SE5 para SE1
E5_RECPAG = 'R'
• Exemplo de preenchimento do SX9
– X9_CDOM X9_DOM
• SD2 SC6
– X9_EXPCDOM X9_EXPDOM
• D2_PEDIDO+D2_ITEMPV C6_NUM+C6_ITEM
– X9_CONDSQL
• Em Branco
• Exemplo de preenchimento do SX9
– X9_CDOM X9_DOM
• SE5 SA1
– X9_EXPCDOM X9_EXPDOM
• E5_CLIFOR+E5_LOJA A1_COD+A1_LOJA
– X9_CONDSQL
• (E5_RECPAG = 'R' and E5_TIPODOC <> 'ES') or
(E5_RECPAG = 'P' and E5_TIPODOC = 'ES') or
E5_TIPO = 'RA'
• AtuSX
– Cada tabela terá um responsável. Somente
ele poderá efetuar manutenções em sua
estrutura.
– Toda manutenção de campo ficará pendente
no AtuSX aguardando a aprovação do D.A.
Somente após esta aprovação a alteração
será incorporada à base do AtuSX.
• Datas
– 06.02 - Prazo final para definição dos
responsáveis (donos) das tabelas.
– 10.02 - Prazo final para disponibilização do
AtuSx com nova estrutura
– 28.02 - Prazo final para fechamento das
tabelas SX3, SX9, SXB.
– 28.02 - Entrega das rotinas de geração de
integridade
– 06.03 - Início dos testes
Dúvidas

Apresentação - Coord

Enviado por

Direitos autorais:

Formatos disponíveis

Apresentação - Coord

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apresentação - Coord

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto Integridade Referencial

– Eliminar atributos que dependam de outros

E5_BANCO FK3 ID_SA6 A1_COD

– Ganho de performance ao fazer join

Você também pode gostar