O Sistema Único de Saúde (SUS) é um dos maiores sistemas públicos de saúde do mundo, proporcionando atendimento universal e gratuito à população brasileira. Para garantir eficiência e precisão na gestão dos serviços, uma instituição vinculada ao SUS mantém um banco de dados relacional que registra informações de pacientes, doadores de sangue e distribuição de hemoderivados. No entanto, problemas recorrentes de redundância de dados e inconsistências têm comprometido a confiabilidade das informações armazenadas. Durante uma auditoria, a equipe de TI identificou que a tabela Paciente_Doacao contém os seguintes atributos: Ao analisar a estrutura, os especialistas constataram que um mesmo paciente pode realizar múltiplas doações, o que leva à repetição desnecessária de informações como nome, CPF e tipo sanguíneo. Além disso, foi observado que, quando um paciente precisa corrigir um dado pessoal, todas as suas ocorrências na tabela precisam ser modificadas manualmente, o que aumenta o risco de erros e inconsistências. Para resolver esse problema, a equipe aplicou a Terceira Forma Normal (3FN). Assinale a transformação compatível com essa normalização.
- A)Criar a tabela Doacao_Registro, unificando todos os atributos atuais em um único conjunto de dados, evitando a necessidade de múltiplas tabelas e facilitando consultas diretas.
Errada, porque unir tudo em uma única tabela aumenta a redundância e contraria a ideia de normalização.
- B)Criar uma nova tabela Tipo_Sanguineo, contendo os diferentes tipos sanguíneos disponíveis e referenciá-la na tabela Paciente, eliminando a repetição dessa informação.
Errada, porque o tipo sanguíneo é um atributo do paciente e, sozinho, não resolve a repetição provocada pela mistura de dados de paciente com doação.
- C)Criar a tabela Paciente_Historico, armazenando todas as ocorrências de um paciente ao longo do tempo, mantendo a estrutura original para garantir rastreabilidade completa dos registros.
Errada, porque guardar histórico sem separar as entidades não elimina redundância nem corrige a causa da inconsistência.
- D)Criar a tabela Paciente (id_paciente, nome_paciente, CPF_paciente, tipo_sanguineo, data_nascimento), separando os dados da tabela Paciente_Doacao, que passaria a armazenar apenas id_paciente, id_doacao, data_doacao, quantidade_ml e unidade_coletora.
Certa, porque separa os dados do paciente dos dados da doação e usa chave de ligação para evitar repetição e anomalias de atualização.
Gabarito: D
Quando a tabela mistura dados de naturezas diferentes e repete informações do paciente a cada doação, você percebe o clássico problema de redundância. Em modelagem relacional, a saída costuma ser separar as entidades em tabelas próprias e ligar tudo por chaves estrangeiras. Isso reduz repetição, evita anomalias de atualização e melhora a consistência do banco. A Terceira Forma Normal (3FN) pede, em resumo, que cada atributo não-chave dependa apenas da chave, de toda a chave e de nada além da chave. Na prática, isso significa tirar da tabela de doações os dados que pertencem ao paciente, como nome, CPF e tipo sanguíneo, deixando nessa tabela apenas o que descreve a doação e a referência ao paciente. É o tipo de limpeza que organiza a casa e ainda evita que você arrume o mesmo quarto dez vezes. Por isso, o gabarito é a letra D. Ela faz exatamente a decomposição esperada: cria a tabela Paciente com os dados cadastrais do paciente e mantém na Paciente_Doacao apenas os dados da doação, vinculando tudo por id_paciente. Assim, se o nome ou CPF mudar, você atualiza uma única linha, e não uma coleção de cópias espalhadas pelo banco. Esse raciocínio está alinhado ao princípio de normalização clássico da teoria relacional de Codd: reduzir redundância e dependências indevidas entre atributos. Em concurso, sempre desconfie de alternativas que mantêm os dados repetidos "para facilitar consulta" porque isso costuma facilitar mais a bagunça do que a gestão.