none
Tabelas com dados Repetidos RRS feed

  • Pergunta

  • Bom dia, pessoal! 

    Estou com o seguinte dilema, tenho um banco de dados que conta com tabelas com tuplas repetidas e atributos multi-valorados, quem implementou este banco deve ter faltado na aula de normalização, se é que fez.

    Bem, segue abaixo um exemplo de uma das tabelas 

    [G010_G000_ID] 

    ,[G010_G150_ID]

          ,[G010_G001_ID]

          ,[G010_NOME]

          ,[G010_TELEFONE]

          ,[G010_CPF]

          ,[G010_DATA_NASCIMENTO]

          ,[G010_ENDERECO]

          ,[G010_CEP]

          ,[G010_CIDADE]

          ,[G010_NUMERO]

          ,[G010_BAIRRO]

          ,[G010_COMPLEMENTO]

          ,[G010_CELULAR]

          ,[G010_EMAIL]

          ,[G010_OBSERVACOES]

          ,[G010_DIA_VENCIMENTO]

          ,[G010_PESQUISA_RAPIDA]

          ,[G010_NUMERO_MEDIDOR]

          ,[G010_ORDEM]

          ,[G010_FATOR_CONVERSAO]

          ,[G010_CORREIO]

          ,[G010_TAXA_COMPENSACAO]

          ,[G010_TAXA_COMPENSACAO_DIF]

          ,[G010_APLICA_DESCONTO]

          ,[G010_RG]

          ,[G010_LOGIN]

          ,[G010_DATA_ALTERACAO]

     

    O dilema é o seguinte continuo a usar o banco do jeito que está ou eu faço um novo banco de dados?

    Quero salientar que há duas aplicações rodando com este banco de dados e que as tabelas não possui chave primária. Este banco de dados já existe há mais de 10 anos e contém dados desde 2000.

    Caros colegas é muito importante suas opiniões para mim, pois não tenho experiência em estruturação de banco de dados.

    Trabalho com SQL Server 2008.

    Estou aberto a qualquer opinião.

    Abraços

    Rafael  

    terça-feira, 20 de dezembro de 2011 12:50

Respostas

  • Rafael,

    Minha opinião a respeito é a seguinte, pelo que você descreve realmente existem problemas na estruturação do seu BD. Você fez uma analise a nivel de banco, mas e a nivel de aplicação? As vezes essas consistencias que não existem no banco existem no programa.

    Já vi bancos onde não existem FK's, e o banco é enorme. Mas todo o controle quem faz é o programa. Então se você mexer na estrutura do banco, bem provavel a aplicação deverá ser mexida.

    Neste caso tem que avaliar o custo disso. Será que compensa alterar o BD e a aplicação? Uma vez que você disse que a aplicação funciona a 10 anos assim.

    Sempre sou a favor de melhorar as rotinas que nós sabemos que estão erradas, mas (sempre tem um "mas"!!!!) neste seu caso compensaria?

    Essa analise tem que ser feita com muito cuidado juntamente aos programadores. E como diz o velho ditado: Time que está ganhando não se mexe!!! Mas se precisar mexer, tem que avaliar os custos disso....E poderão ser altos...

     

    Att.,


    Marco Antônio Pinheiro / MCTS - MCC http://marcoantoniopinheiro.blogspot.com
    terça-feira, 20 de dezembro de 2011 14:14
  • Rafael, bom dia,

    Segue a uma modelagem inicial. Eh claro, podemos normalizar ainda mais como por exemplo controlar as alteracoes nesta tabela, logando os usuarios que fizeram as alteracoes de cada atributo. Para isto poderiamos montar um metadata para controle destas alteracçoes.

      TB_G010_PRINCIPAL
    PK G010_G000_ID
      G010_G150_ID
      G010_G001_ID
      G010_NOME
      G010_CPF
      G010_DATA_NASCIMENTO
      G010_OBSERVACOES
      G010_DIA_VENCIMENTO
      G010_PESQUISA_RAPIDA
      G010_NUMERO_MEDIDOR
      G010_ORDEM
      G010_FATOR_CONVERSAO
      G010_CORREIO
      G010_TAXA_COMPENSACAO
      G010_TAXA_COMPENSACAO_DIF
      G010_APLICA_DESCONTO
      G010_RG
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_ENDERECOS
    PK G010_ENDERECO_ID
    FK G010_G000_ID
      G010_ENDERECO
      G010_CEP
      G010_CIDADE
      G010_NUMERO
      G010_BAIRRO
      G010_COMPLEMENTO
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_EMAILS
    PK G010_EMAIL_ID
    FK G010_G000_ID
      G010_EMAIL
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_TELEFONES
    PK G010_TELEFONE_ID
    FK G010_G000_ID
      G010_TELEFONE
      G010_TIPO_TELEFONE
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

     

    Qualquer duvida estou a disposiçao.

    Abs.

     

     

     

     

     

     

     

     


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp
    quinta-feira, 22 de dezembro de 2011 12:28

Todas as Respostas

  • Rafael,

    Minha opinião a respeito é a seguinte, pelo que você descreve realmente existem problemas na estruturação do seu BD. Você fez uma analise a nivel de banco, mas e a nivel de aplicação? As vezes essas consistencias que não existem no banco existem no programa.

    Já vi bancos onde não existem FK's, e o banco é enorme. Mas todo o controle quem faz é o programa. Então se você mexer na estrutura do banco, bem provavel a aplicação deverá ser mexida.

    Neste caso tem que avaliar o custo disso. Será que compensa alterar o BD e a aplicação? Uma vez que você disse que a aplicação funciona a 10 anos assim.

    Sempre sou a favor de melhorar as rotinas que nós sabemos que estão erradas, mas (sempre tem um "mas"!!!!) neste seu caso compensaria?

    Essa analise tem que ser feita com muito cuidado juntamente aos programadores. E como diz o velho ditado: Time que está ganhando não se mexe!!! Mas se precisar mexer, tem que avaliar os custos disso....E poderão ser altos...

     

    Att.,


    Marco Antônio Pinheiro / MCTS - MCC http://marcoantoniopinheiro.blogspot.com
    terça-feira, 20 de dezembro de 2011 14:14
  • Rafael, boa tarde,

    Eu sugiro uma normalizaçao de dados de forma gradativa, pois o problema nao eh simplesmente normalizar as tabelas e sim os sistemas que utilizam atualmente esta modelagem. Chave primaria eh fundamental. Toda tabela precisa. Vc pode começar por ai. Depois vc pode partir para os campos q tem relacionamento 1 --> N, por exemplo endereço: uma pessoa fisica pode ter mais de um endereço? Se sim eh necessario normalizar. Data_Alteracao. Este dado necessita uma normalizaçao, pois eh dado historico. Vc precisa registrar as ocorrencias de alteraçoes. Enfim, existem varios os campos que eu normalizaria para obter uma modelagem robusta e consistente, mas eh importante fazer estas mudanças de forma a nao impactar os sistemas que consomem estes dados na modelagem atual.

    Se precisar de ajuda, estou a disposiçao.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp
    terça-feira, 20 de dezembro de 2011 14:17
  •  Obrigado! Pelas sugestões.

    Marcos você está corretíssimo na sua observação. Analisando melhor vou seguir seu conselho de não alterar o que está funcionando.

     

    Obrigado!

    quarta-feira, 21 de dezembro de 2011 02:27
  • Rafael, boa tarde,

    Eu sugiro uma normalizaçao de dados de forma gradativa, pois o problema nao eh simplesmente normalizar as tabelas e sim os sistemas que utilizam atualmente esta modelagem. Chave primaria eh fundamental. Toda tabela precisa. Vc pode começar por ai. Depois vc pode partir para os campos q tem relacionamento 1 --> N, por exemplo endereço: uma pessoa fisica pode ter mais de um endereço? Se sim eh necessario normalizar. Data_Alteracao. Este dado necessita uma normalizaçao, pois eh dado historico. Vc precisa registrar as ocorrencias de alteraçoes. Enfim, existem varios os campos que eu normalizaria para obter uma modelagem robusta e consistente, mas eh importante fazer estas mudanças de forma a nao impactar os sistemas que consomem estes dados na modelagem atual.

    Se precisar de ajuda, estou a disposiçao.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    Eduardo, muito obrigado pela sua sugestão estou muito agradecido.

    Mas antes de eu postar estas duas sugestões como resposta, eu queria que você me orientasse melhor, pois estou curioso.

    Como eu faria para desmembrar esta tabela que eu dispus como exemplo nas formas normais, já que como adiantei há um sistema em funcionamento e utiliza este código fazendo busca nesta tabela?

     Sei que parece que estou te desafiando  acima, porém não é desafio não! É pura ignorância mesmo. Se for muita ignorância peço que a desconsidere e por favor me oriente, pois sem esta orientação estarei perdido.

     

    Abraços

    Rafael

     

    Obrigado novamente!

    quarta-feira, 21 de dezembro de 2011 02:41
  • Sem problemas Rafael, estou aqui pra ajudar. Eh claro que te ajudo sim, mas para direcionar uma melhor modelagem preciso de algumas respostas:

    1 - Volume em registros dessa tabela

    2 - Periodicidade de atualizacao da mesma

    3 - [G010_DATA_ALTERACAO] se refere a qual alteraçao? Da pessoa? Do login?

    4 - Vc pode ter varios telefones para a pessoa fisica?

    5 - Vc pode ter varios endereços para a pessoa fisica?

    me adiciona no msn... ai passo mais detalhes.

    edugp_sp@hotmail.com


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp
    quarta-feira, 21 de dezembro de 2011 11:17
  • Sem problemas Rafael, estou aqui pra ajudar. Eh claro que te ajudo sim, mas para direcionar uma melhor modelagem preciso de algumas respostas:

    1 - Volume em registros dessa tabela

    2 - Periodicidade de atualizacao da mesma

    3 - [G010_DATA_ALTERACAO] se refere a qual alteraçao? Da pessoa? Do login?

    4 - Vc pode ter varios telefones para a pessoa fisica?

    5 - Vc pode ter varios endereços para a pessoa fisica?

    me adiciona no msn... ai passo mais detalhes.

    edugp_sp@hotmail.com


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    Olá Eduardo! Valeu pela disposição, fico feliz de poder contar com pessoas como você também gosto de ajudar os outros, segue abaixo algumas considerações solicitadas. 

     

    1- O volume em registro é de 45.000

    2-

    a - número médio de leitura lógicas em (ms) :  11,93

    b - número médio de gravações lógicas (ms) : 2,20

    3- Se refere a um histórico de alteração da pessoa, mostrando também o usuário que fez a alteração

    4- Posso ter vários telefones

    5 -  Posso ter 2 endereços  1  do imóvel e outro de cobrança 

     

    Obrigado!

    Abraços

    Rafael

    quinta-feira, 22 de dezembro de 2011 12:12
  • Rafael, bom dia,

    Segue a uma modelagem inicial. Eh claro, podemos normalizar ainda mais como por exemplo controlar as alteracoes nesta tabela, logando os usuarios que fizeram as alteracoes de cada atributo. Para isto poderiamos montar um metadata para controle destas alteracçoes.

      TB_G010_PRINCIPAL
    PK G010_G000_ID
      G010_G150_ID
      G010_G001_ID
      G010_NOME
      G010_CPF
      G010_DATA_NASCIMENTO
      G010_OBSERVACOES
      G010_DIA_VENCIMENTO
      G010_PESQUISA_RAPIDA
      G010_NUMERO_MEDIDOR
      G010_ORDEM
      G010_FATOR_CONVERSAO
      G010_CORREIO
      G010_TAXA_COMPENSACAO
      G010_TAXA_COMPENSACAO_DIF
      G010_APLICA_DESCONTO
      G010_RG
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_ENDERECOS
    PK G010_ENDERECO_ID
    FK G010_G000_ID
      G010_ENDERECO
      G010_CEP
      G010_CIDADE
      G010_NUMERO
      G010_BAIRRO
      G010_COMPLEMENTO
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_EMAILS
    PK G010_EMAIL_ID
    FK G010_G000_ID
      G010_EMAIL
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

      TB_G010_TELEFONES
    PK G010_TELEFONE_ID
    FK G010_G000_ID
      G010_TELEFONE
      G010_TIPO_TELEFONE
      G010_DT_INCLUSAO
      G010_DT_ALTERACAO
      G010_ID_LOGIN

     

     

    Qualquer duvida estou a disposiçao.

    Abs.

     

     

     

     

     

     

     

     


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp
    quinta-feira, 22 de dezembro de 2011 12:28
  • Obrigado, novamente.
    quinta-feira, 22 de dezembro de 2011 13:04