Questão de Banco de Dados — Normalização — FGV 2024
Banco de Dados›Normalização
Código
fg165255
Banca
FGV
Órgão
TJ MS
Ano
2024
Cargo
Tec NS ( )
A normalização de dados é o processo de analisar os esquemas de relações com base nas dependências funcionais de seus atributos e chaves primárias, envolvendo uma série de Formas Normais (FN). Observe o esquema da tabela “Pedido”, a seguir.
ID_PEDIDO
ID_CLIENTE
DATA
NOME_CLIENTE
1
2
16/04/2024
Luiza
2
3
16/04/2024
Júlia
A tabela "Pedido" possui chave primária composta (ID_PEDIDO, ID_CLIENTE), atributos com valores atômicos e dependência parcial de coluna não chave (NOME_CLIENTE) com parte da chave primária (ID_CLIENTE).
Com base nisso, “Pedido” está normalizada na FN:
A1FN;
B2FN;
C3FN;
D4FN;
E5FN.
Revelar gabarito e comentário▾
GabaritoA — 1FN;
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”.
Normalização de Dados: Formas Normais e Dependências Funcionais
Gabarito: letra A — a tabela “Pedido” está normalizada apenas na 1FN. O enunciado afirma que os atributos têm valores atômicos (satisfaz a 1FN), mas há dependência parcial de NOME_CLIENTE em relação a ID_CLIENTE, que é parte da chave primária composta (ID_PEDIDO, ID_CLIENTE). Essa dependência parcial viola a 2FN, que exige que todo atributo não chave dependa da chave primária completa.
A normalização é o processo de analisar esquemas de relações com base nas dependências funcionais entre atributos e chaves primárias, com o objetivo de minimizar redundâncias e anomalias de inserção, exclusão e atualização. As formas normais são regras progressivas: para estar em uma forma normal superior, a tabela deve atender a todas as anteriores. A 1FN exige que todos os atributos sejam atômicos (sem valores compostos ou multivalorados). A 2FN, além da 1FN, exige que não haja dependência parcial de atributos não chave em relação a parte da chave primária composta. A 3FN, por sua vez, exige que não haja dependência transitiva entre atributos não chave.
No caso da tabela “Pedido”, a chave primária é composta por (ID_PEDIDO, ID_CLIENTE). O atributo NOME_CLIENTE depende funcionalmente de ID_CLIENTE, que é apenas parte da chave. Isso caracteriza uma dependência parcial, que é exatamente a violação da 2FN. Como a tabela já está na 1FN (valores atômicos), mas não atende à 2FN, ela permanece na 1FN. A presença de dependência parcial impede que a tabela alcance a 2FN, e consequentemente as formas superiores (3FN, 4FN, 5FN) também não são atingidas.
Para visualizar, imagine que o mesmo cliente faça dois pedidos diferentes: o nome do cliente apareceria repetido em cada linha, pois depende apenas do ID_CLIENTE, não do pedido completo. Isso gera redundância e anomalias de atualização — se o cliente mudar de nome, seria necessário atualizar todas as linhas referentes a ele. A solução seria separar os dados do cliente em uma tabela própria, eliminando a dependência parcial.
A pegadinha desta questão está em reconhecer que a dependência parcial é o critério que separa a 1FN da 2FN. Muitos candidatos, ao verem valores atômicos, já assumem que a tabela está na 2FN, mas esquecem de verificar se há dependência parcial. A banca explora exatamente essa confusão: a tabela está na 1FN, mas não na 2FN, porque a dependência parcial viola a regra da 2FN.
Critério
1FN (atual)
2FN (exigida)
Valores atômicos
✅ Satisfeito (enunciado)
✅ Necessário
Dependência parcial de atributo não chave
❌ Presente (NOME_CLIENTE → ID_CLIENTE)
❌ Proibida
Dependência da chave primária completa
❌ Não atende
✅ Exigida
Forma normal alcançada
✅ Máxima atingida
❌ Não alcançada
Alternativa A — ✅ Correta ⟵ GABARITO
A tabela está na 1FN, pois todos os atributos possuem valores atômicos, conforme o enunciado. No entanto, a existência de dependência parcial de NOME_CLIENTE em relação a ID_CLIENTE (parte da chave primária composta) impede que a tabela atinja a 2FN. Portanto, a forma normal máxima é a 1FN.
Alternativa B — ❌ Incorreta
A 2FN exige que a tabela esteja na 1FN e que não haja dependência parcial de atributos não chave em relação à chave primária. Como o enunciado afirma explicitamente que há dependência parcial de NOME_CLIENTE com parte da chave (ID_CLIENTE), a tabela viola a 2FN. Portanto, não pode estar na 2FN.
Alternativa C — ❌ Incorreta
A 3FN exige que a tabela esteja na 2FN e que não haja dependência transitiva entre atributos não chave. Como a tabela não está na 2FN (devido à dependência parcial), ela não pode estar na 3FN. A dependência transitiva é um requisito adicional, mas a falha na 2FN já elimina essa possibilidade.
Alternativa D — ❌ Incorreta
A 4FN exige que a tabela esteja na 3FN e que não haja dependências multivaloradas. Como a tabela não está na 3FN (e nem na 2FN), ela não pode estar na 4FN. A dependência multivalorada é um conceito mais avançado, mas a falha nas formas anteriores já impede a 4FN.
Alternativa E — ❌ Incorreta
A 5FN exige que a tabela esteja na 4FN e que não haja dependências de junção. Como a tabela não está na 4FN (e nem nas anteriores), ela não pode estar na 5FN. A 5FN é a forma mais restritiva, mas a falha na 2FN já elimina essa possibilidade.
NÃO CAIA NESSA!
A banca explora a confusão entre valores atômicos (1FN) e dependência parcial (violação da 2FN). Muitos candidatos, ao verem que os atributos são atômicos, já marcam 2FN, mas esquecem de verificar se há dependência parcial. A questão afirma explicitamente que NOME_CLIENTE depende de ID_CLIENTE, que é parte da chave — isso é a pegadinha clássica. Fique atento: a 2FN só é satisfeita se todo atributo não chave depender da chave primária completa.