Questão de Banco de Dados — Formas normais — FCC 2015
Banco de Dados›Formas normais
Código
fc019070
Banca
FCC
Órgão
DPE-SP
Ano
2015
Nível
Superior
Cargo
Administrador de Banco de Dados
Considere ainda que todo atendimento é individual e gera um registro de atendimento sempre diferente em cada atendimento e que cada cliente pode fornecer apenas um endereço de e-mail.Para que a entidade Atendimento esteja na segunda forma normal é necessário que o atributo.
Acpf_advogado também faça parte de chave primária composta.
Bcpf_advogado seja transferido para a entidade Advogado e o atributo email_cliente para a entidade Cliente.
Cregistro_atendimento seja colocado em uma entidade auxiliar ligada à entidade Atendimento.
Ddata_hora não faça parte de chave primária composta.
Eregistro_atendimento seja retirado da entidade Atendimento e colocado na entidade Advogado, pois é o advogado que registra o atendimento.
Revelar gabarito e comentário▾
GabaritoB — cpf_advogado seja transferido para a entidade Advogado e o atributo email_cliente para a entidade Cliente.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Segunda Forma Normal (2FN) em Banco de Dados
Gabarito: letra B. Para que a entidade Atendimento esteja na segunda forma normal (2FN), é necessário eliminar as dependências parciais de atributos não chave em relação à chave primária composta. A chave primária de Atendimento é (OAB_advogado, id_cliente, data_hora). Os atributos email_cliente dependem apenas de id_cliente (parte da chave) e cpf_advogado depende apenas de OAB_advogado (outra parte da chave). A solução é transferir esses atributos para suas respectivas entidades (Cliente e Advogado), conforme previsto na definição de 2FN.
A normalização tem como objetivo reduzir redundâncias e evitar anomalias. A definição de 2FN, conforme o conteúdo de apoio (questões de concursos VUNESP), estabelece que uma tabela está na 2FN se estiver na 1FN e todo atributo não chave depender funcionalmente da totalidade da chave primária, não de parte dela. Isso significa que não pode haver dependências parciais.
Alternativa B — ✅ Correta ⟵ GABARITO
A alternativa propõe transferir cpf_advogado para a entidade Advogado e email_cliente para a entidade Cliente. Ao fazer isso, eliminam-se as dependências parciais, pois email_cliente passa a depender apenas de id_cliente (chave de Cliente) e cpf_advogado apenas de OAB_advogado (chave de Advogado). A entidade Atendimento fica então com atributos que dependem da chave completa, cumprindo a 2FN.
Alternativa A — ❌ Incorreta
Incluir cpf_advogado na chave primária composta não resolve a dependência parcial. Na verdade, tornaria a chave ainda mais artificial e não eliminaria a dependência funcional de cpf_advogado em relação a OAB_advogado (que já é parte da chave). Além disso, email_cliente continuaria dependendo apenas de id_cliente, persistindo a violação.
Alternativa C — ❌ Incorreta
O atributo registro_atendimento é dependente da chave completa (cada atendimento gera um registro diferente, conforme enunciado). Portanto, não há dependência parcial – ele já está em conformidade com a 2FN. Movê-lo para uma entidade auxiliar é desnecessário e não corrige as dependências parciais dos outros atributos.
Alternativa D — ❌ Incorreta
Retirar data_hora da chave primária composta descaracterizaria a identificação única de cada atendimento. A chave perderia a capacidade de distinguir atendimentos de um mesmo advogado com um mesmo cliente em momentos diferentes. Além disso, não resolveria as dependências parciais de email_cliente e cpf_advogado.
Alternativa E — ❌ Incorreta
Transferir registro_atendimento para a entidade Advogado é semanticamente errado, pois o registro é específico de cada atendimento, não do advogado. Cada advogado pode ter vários atendimentos, cada um com seu próprio registro. Isso criaria uma dependência funcional inadequada e violaria a 1FN (pois um advogado teria vários registros em um único atributo, ou exigiria uma nova tabela).
NÃO CAIA NESSA!
A banca tenta confundir o candidato com soluções que parecem lógicas, como incluir cpf_advogado na chave (alternativa A) ou mexer em registro_atendimento (C e E), quando o real problema são as dependências parciais. A chave para identificar a violação da 2FN é perceber que email_cliente depende de apenas parte da chave (id_cliente) e cpf_advogado depende de outra parte (OAB_advogado).
PEGA ESSA DICA!
Sempre que uma tabela tiver chave primária composta, verifique se cada atributo não chave depende funcionalmente da totalidade da chave. Se algum atributo depende apenas de parte da chave, ele deve ser movido para outra tabela (com a parte da chave como chave primária da nova tabela). É o que cai em provas de normalização.