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

Normalização de dados: aplicando a 3FN

Gabarito: letra C. A terceira forma normal (3FN) exige que a tabela esteja na 2FN e que nenhum atributo não-chave dependa transitivamente da chave primária — ou seja, cada atributo deve depender exclusivamente da chave. No caso, nome_servidor e cargo_servidor dependem do servidor (não da intimação), e tipo_intimacao é um valor padronizado que se repete; a solução correta é decompor em tabelas relacionadas (Servidores, Tipos_Intimacao e Intimacoes) com chaves estrangeiras, eliminando as dependências transitivas e a redundância.

A normalização é o processo de organizar os dados de um banco relacional para reduzir redundância e evitar anomalias de inserção, exclusão e atualização. Ela se dá por meio das formas normais, que são regras cumulativas: para estar na 3FN, a tabela precisa antes estar na 1FN e na 2FN. A 1FN exige atributos atômicos (sem valores multivalorados ou compostos). A 2FN exige que todo atributo não-chave dependa da chave primária inteira (dependência funcional total), eliminando dependências parciais — isso só é relevante quando a chave é composta. A 3FN, por sua vez, elimina as dependências transitivas: um atributo não-chave não pode depender de outro atributo não-chave, que por sua vez depende da chave.

No problema apresentado, a tabela Intimacoes tem id_intimacao como chave primária. Os atributos nome_servidor e cargo_servidor não dependem da intimação, mas sim do servidor — há uma dependência transitiva: id_intimacao → nome_servidor → cargo_servidor. Já tipo_intimacao é um valor de uma lista padronizada, que se repete em várias intimações, gerando redundância. A solução é decompor a tabela em três: Servidores (com id_servidor, nome_servidor, cargo_servidor), Tipos_Intimacao (com id_tipo, tipo_intimacao) e Intimacoes (com id_intimacao, id_servidor (FK), id_tipo (FK), data_intimacao, descricao_intimacao). Assim, cada fato é armazenado uma única vez, e as chaves estrangeiras garantem a integridade referencial.

Um exemplo prático: se o servidor "João" for intimado 10 vezes, na tabela original seu nome e cargo apareceriam 10 vezes. Se ele mudar de cargo, seria necessário atualizar 10 registros — uma anomalia de atualização. Com a decomposição, o cargo de João fica armazenado uma única vez na tabela Servidores; uma única atualização reflete em todas as intimações. O mesmo vale para o tipo de intimação: se a descrição de um tipo padronizado mudar, basta alterar um registro em Tipos_Intimacao.

A pegadinha desta questão é confundir normalização com desempenho ou com soluções superficiais. A normalização não tem como objetivo melhorar a performance — pelo contrário, tabelas normalizadas podem gerar consultas mais lentas devido a joins. O objetivo é eliminar redundância e anomalias. Alternativas que propõem views, índices ou manter tudo em uma tabela não resolvem o problema lógico de dependências transitivas. A alternativa que propõe normalizar apenas descricao_intimacao também está errada, pois esse campo não é a fonte da redundância — os problemas estão em nome_servidor, cargo_servidor e tipo_intimacao.

Guarde o critério decisivo: para aplicar a 3FN, identifique as dependências transitivas (atributo não-chave dependendo de outro atributo não-chave) e decomponha em tabelas separadas, usando chaves estrangeiras para manter o relacionamento. É exatamente isso que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Criar uma view e aplicar restrições de chave estrangeira apenas na visualização lógica não resolve o problema. Uma view é uma consulta armazenada, não uma estrutura física; ela não elimina a redundância nem as dependências transitivas na tabela base. Além disso, chaves estrangeiras são definidas nas tabelas físicas, não em views. A normalização exige decomposição real das tabelas, não uma "ilusão" de normalização por meio de views.

Alternativa B — ❌ Incorreta

Normalizar apenas descricao_intimacao não ataca o problema. Esse campo é um texto variável que depende diretamente da intimação (id_intimacao), portanto não gera dependência transitiva nem redundância significativa. Os atributos problemáticos são nome_servidor, cargo_servidor (dependência transitiva) e tipo_intimacao (valor repetido de lista padronizada). A alternativa confunde o campo que "parece" variável com a real fonte de redundância.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a aplicação correta da 3FN. Decompor em Servidores, Tipos_Intimacao e Intimacoes elimina as dependências transitivas: nome_servidor e cargo_servidor passam a depender da chave de Servidores, e tipo_intimacao passa a depender da chave de Tipos_Intimacao. As chaves estrangeiras em Intimacoes (id_servidor, id_tipo) garantem a integridade referencial e eliminam a redundância, pois cada dado é armazenado uma única vez.

Alternativa D — ❌ Incorreta

Manter todos os atributos na mesma tabela e criar índices compostos não elimina a redundância lógica. Índices melhoram o desempenho de consultas, mas não resolvem o problema de dependências transitivas nem evitam a repetição de nome_servidor, cargo_servidor e tipo_intimacao. A normalização é uma questão de modelagem lógica, não de otimização física. A alternativa confunde o papel dos índices (performance) com o da normalização (eliminar redundância).

Alternativa E — ❌ Incorreta

Eliminar cargo_servidor e parar na 2FN não é a solução. Remover um atributo não resolve a dependência transitiva de nome_servidor (que ainda dependeria do servidor, não da intimação). Além disso, a 2FN trata de dependências parciais (relevante apenas com chave composta), não de dependências transitivas — que são o foco da 3FN. A justificativa de que "dividir em mais tabelas tornaria o sistema mais lento" é uma falácia: a normalização pode gerar joins, mas o objetivo aqui é eliminar redundância e anomalias, não otimizar performance.

Gabarito: letra C