Questão de Banco de Dados — Normalização — FCC 2026

Normalização: Segunda Forma Normal (2FN) e dependência parcial

Gabarito: letra D. Para que a tabela AtuacaoInfracao atenda à 2FN, é necessário eliminar as dependências parciais: NomePromotor depende apenas de PromotorID e TipoInfracao depende apenas de InfracaoID, enquanto a chave é composta por ambos. A solução correta é decompor a relação em três tabelas — Promotor, Infracao e AtuacaoInfracao —, cada uma com seus atributos plenamente dependentes da chave inteira.

A normalização é um processo de análise de esquemas relacionais com base em dependências funcionais e chaves primárias, com o objetivo de minimizar redundâncias e evitar anomalias de inserção, exclusão e atualização. A 2FN é uma das formas normais que trata especificamente das dependências parciais: uma relação está na 2FN se estiver na 1FN e cada atributo não-chave for total e funcionalmente dependente da chave primária (ou candidata) inteira. Em outras palavras, nenhum atributo não-chave pode depender de apenas uma parte de uma chave composta.

No caso da tabela AtuacaoInfracao, a chave primária é (PromotorID, InfracaoID). Os atributos NomePromotor e TipoInfracao são não-chave, mas cada um depende de apenas uma parte da chave: NomePromotor depende de PromotorID (um promotor tem um nome), e TipoInfracao depende de InfracaoID (uma infração tem um tipo). Isso configura dependências parciais, violando a 2FN. Para corrigir, decompõe-se a relação em três:

• Promotor (PromotorID, NomePromotor) — chave PromotorID;

• Infracao (InfracaoID, TipoInfracao) — chave InfracaoID;

• AtuacaoInfracao (PromotorID, InfracaoID, DataInicioInvestigacao) — chave composta (PromotorID, InfracaoID), onde DataInicioInvestigacao depende da chave inteira (a data de início da investigação é específica da combinação promotor-infração).

Essa decomposição elimina as dependências parciais e coloca a tabela na 2FN. É importante notar que a normalização não tem como objetivo melhorar a performance — na verdade, tabelas normalizadas podem gerar consultas mais complexas (com joins), mas garantem integridade e reduzem redundância. A pegadinha da banca aqui é justamente confundir a solução de normalização com outras abordagens, como criar um identificador artificial ou manter atributos calculados.

Guarde o critério decisivo: a 2FN exige que todo atributo não-chave dependa da chave inteira, não de parte dela. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Criar um identificador artificial (AtuacaoID) e manter todos os atributos na mesma tabela não elimina as dependências parciais. O problema não é a chave composta em si, mas o fato de NomePromotor e TipoInfracao dependerem de apenas parte da chave. Mesmo com uma chave substituta, essas dependências parciais continuariam existindo, e a tabela ainda violaria a 2FN. Além disso, manter NomePromotor e TipoInfracao na mesma tabela preservaria a redundância (o nome do promotor se repetiria para cada infração que ele investiga).

Alternativa B — ❌ Incorreta

Transformar NomePromotor e TipoInfracao em atributos calculados (buscados em outras fontes durante a consulta) não é uma solução de normalização e não altera o esquema original. Na prática, isso seria uma forma de view ou consulta com joins, mas não resolve a violação da 2FN na estrutura da tabela. Além disso, a ideia de "atributos calculados" é estranha ao modelo relacional — atributos devem ser armazenados, não calculados em tempo de consulta (isso seria uma visão materializada ou uma consulta, não uma normalização).

Alternativa C — ❌ Incorreta

Criar as tabelas Promotor e Infracao mantendo a tabela original não resolve o problema: a tabela AtuacaoInfracao original continuaria com NomePromotor e TipoInfracao, e as dependências parciais persistiriam. A alternativa C sugere criar as duas tabelas, mas não remove os atributos redundantes da tabela original — ela apenas adiciona novas tabelas, sem decompor a relação. Para atingir a 2FN, é necessário remover NomePromotor e TipoInfracao da tabela de relacionamento, o que só a alternativa D faz.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta é a decomposição correta: separa Promotor (com NomePromotor), Infracao (com TipoInfracao) e AtuacaoInfracao (apenas com a chave composta e DataInicioInvestigacao). Assim, cada atributo não-chave depende da chave inteira de sua respectiva tabela: NomePromotor depende de PromotorID, TipoInfracao depende de InfracaoID, e DataInicioInvestigacao depende de (PromotorID, InfracaoID). Isso elimina as dependências parciais e coloca todas as relações na 2FN.

Alternativa E — ❌ Incorreta

Eliminar o campo TipoInfracao da tabela principal e recuperá-lo em consultas não resolve a dependência parcial de NomePromotor. A tabela ainda teria NomePromotor, que depende apenas de PromotorID, violando a 2FN. Além disso, a alternativa E não propõe a criação de uma tabela Infracao — apenas remove o atributo, o que não é uma solução de normalização adequada (e ainda deixaria a dependência parcial de NomePromotor).

Gabarito: letra D