Pular para o conteúdo principal

Questão de Banco de Dados — Normalização — FGV 2024

Banco de DadosNormalizaçã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:

  1. A1FN;
  2. B2FN;
  3. C3FN;
  4. D4FN;
  5. 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.

Gabarito: letra A

Link permanente: /questoes/fg165255