Questão de Tecnologia da Informação · CESGRANRIO BASA 02/2021 (nº 35)

Conceito-chave: A 3FN exige que todo atributo não-chave dependa apenas da chave primária, e não de outros atributos não-chave (chamada dependência transitiva). Aqui, UF depende de cidade, que não é chave — isso viola a 3FN.

• (A) Incorreta: A tabela já está na 1FN (não há atributos multivalorados), então a violação não é de 1FN; além disso, separar telefone em outra tabela seria para resolver multivalorado, o que não existe aqui.
• (B) Incorreta: Mesma armadilha da letra A: não há violação de 1FN, e separar conta-corrente em outra tabela não resolve a dependência transitiva de UF com cidade.
• (C) Correta: A violação é de 3FN porque UF depende de cidade (dependência transitiva via CPF → cidade → UF). A solução correta é criar a tabela CIDADE (cidade, UF) e remover UF de CLIENTE-v2, mantendo cidade como chave estrangeira.
• (D) Incorreta: A 2FN só se aplica a chaves compostas; aqui a chave é simples (CPF), então não há violação de 2FN. Além disso, juntar conta-corrente e telefone em uma tabela não resolve a transitividade.
• (E) Incorreta: A violação é de 3FN, mas a solução proposta está errada: separar endereço, cidade e UF em outra tabela não elimina a dependência transitiva de UF com cidade (que continuaria na tabela CLIENTE_ENDERECO); o correto é isolar cidade → UF na tabela CIDADE.

Armadilha da banca (distrator mais tentador, letra E): Ela usa o nome "3FN" corretamente, mas propõe uma decomposição que não remove a dependência transitiva — UF ainda dependeria de cidade dentro da tabela CLIENTE_ENDERECO. A banca testa se você entende que a solução exige criar uma tabela específica para a dependência funcional cidade → UF, não apenas agrupar atributos de endereço.