none
Redundância RRS feed

  • Discussão Geral

  • Olá Pessoal,

    Preciso da opinião de vcs.
    Estou criando uma base de dados para armazenar informações sobre os prontuários de pacientes de uma clínica.
    Estas informações deverão ter a máxima segurança, pois o armazenamento é para vida toda.

    tbPaciente
    -IdPaciente (PK)
    -Nome

    tbAtendimento
    -IdAtendimento (PK)
    -IdPaciente (FK)

    tbRequisicao
    -IdRequisicao (PK)
    -IdAtendimento (FK)

    tbExame
    -IdExame (PK)
    -IdRequisicao (FK)
    -IdCliente

    Em um processo normalizado, sei que é redundante colocar o campo IdPaciente na tabela "tbExame".
    Desejo inserir este campo, para facilitar as pesquisas, como tambem manter segura as informações do paciente, caso ocorra algum problema (danificação) com as tabelas superioras.
    Vejam bem, o campo IdPaciente tambem irá fazer parte de outras tabelas, pois a tabela tbAtendimento será o núcleo da modelagem.
    A minha pergunta é: A inserção deste campo tornaria a modelagem fora dos padrões de normalização ?
    Qualquer opinião será bem vinda,

    obrigado

    Pedro

      

    • Tipo Alterado Heloisa Pires segunda-feira, 2 de abril de 2012 19:37
    sexta-feira, 30 de março de 2012 18:51

Todas as Respostas

  • Bom Dia,

    Bom Dia,

    Ao meu ver (possivelmente por não ter toda a contextualização que você possui), acredito que a tabela tbAtendimento e tbRequisicao são um tanto desnecessárias já que não possuem nenhuma outra característica que não a sua chave primária e uma FK com o paciente. A menos que você tenha ocultado os demais atributos de propósito, não vejo necessidade delas nesse modelo.

    Supondo que um atendimento seja uma consulta e que a consulta demande vários exames, faz sentido sim, a existência dessa tabela e pelas regras de normalização, o ID do paciente deve ser utilizado na tabela de atendimentos, mas não na tabela de exames. O paciente fez uma consulta e essa consulta demandou vários exames. Tê-lo em duas tabelas dá margem a inconsistências e pelas regras não deve estar na tabela de exames.

    É naturalmente esperado que se pergunte quais são os exames que o paciente fez e isso forcará um JOIN entre paciente, atendimento e exame e com certeza fazer um JOIN entre paciente e exame é mais rápido. Ainda assim, não considero válida essa alternativa apenas por isso. Veja que manter a FK com o paciente irá ocupar mais espaço e também tem o custo de manutenção (triggers possivelmente). Além do mais, ser mais rápido, não significa que a implementação anterior seja lenta. É um JOIN a mais com certeza, mas isso não significa apresentar um desempenho ruim ou inaceitável.

    Inicialmente eu não incluiria essa chave. Só o faria se tivesse elementos que confirmassem que o ganho de desempenho é certo e necessário. Se facilitar consultas fosse justificativa suficiente não teríamos nada normalizado

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível


    domingo, 1 de abril de 2012 15:02