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

Normalização: Primeira Forma Normal (1FN)

Gabarito: letra E. Para que a tabela atinja a 1FN, a coluna Telefones — que armazena múltiplos valores separados por ";" — deve ser eliminada, criando-se uma tabela separada Telefones (ColaboradorID, Telefone), com cada telefone em uma linha própria. A 1FN exige que todos os atributos sejam atômicos, ou seja, que nenhuma coluna contenha valores multivalorados ou compostos.

A Primeira Forma Normal é o requisito fundamental do modelo relacional: cada célula da tabela deve conter um único valor indivisível. No exemplo dado, a coluna Telefones viola essa regra ao armazenar dois números separados por ponto e vírgula na mesma linha. Para corrigir, é preciso separar os dados em duas tabelas relacionadas: uma para os colaboradores e outra para os telefones, onde cada telefone ocupa uma linha distinta, referenciando o colaborador por uma chave estrangeira.

A normalização, de forma geral, busca eliminar redundâncias e anomalias de inserção, exclusão e atualização. No caso específico da 1FN, o foco é garantir a atomicidade dos dados. Se um colaborador tem dois telefones, a solução não é repetir os dados do colaborador em duas linhas (o que criaria redundância e problemas de atualização), nem criar colunas fixas para um número limitado de telefones (o que não resolve o problema para quem tem mais telefones que o previsto), nem manter os valores em um campo JSON (que continua sendo um campo multivalorado). A solução correta é a decomposição em duas tabelas.

A pegadinha desta questão está em confundir a 1FN com outras abordagens que até resolvem o problema de armazenamento, mas não seguem o princípio da atomicidade. A banca explora a tentação de "achar um jeito" de guardar os múltiplos valores sem quebrar a tabela, quando a única forma correta é a separação em uma nova relação.

Guarde o critério decisivo: 1FN = atributos atômicos. Qualquer alternativa que mantenha múltiplos valores em uma única coluna — seja por separador, JSON ou colunas fixas — viola a 1FN. A única saída é criar uma tabela auxiliar.

Alternativa A — ❌ Incorreta

Repetir o registro do colaborador para cada telefone na mesma tabela resultaria em múltiplas linhas com o mesmo ColaboradorID, o que viola o princípio da chave primária (que deve ser única) e introduz redundância de dados. Essa abordagem não é a forma correta de atingir a 1FN, pois cria anomalias de atualização e exclusão.

Alternativa B — ❌ Incorreta

Colocar os telefones em um campo JSON (array ou lista) mantém a coluna Telefones como um atributo multivalorado. A 1FN exige que cada atributo seja atômico, e um campo JSON com múltiplos valores continua sendo um campo composto, violando a forma normal.

Alternativa C — ❌ Incorreta

Manter a tabela com a coluna Telefones como texto com separador padrão não resolve o problema. A coluna continua armazenando múltiplos valores em uma única célula, o que é exatamente o que a 1FN proíbe. A atomicidade não é alcançada apenas padronizando o separador.

Alternativa D — ❌ Incorreta

Substituir a coluna Telefones por duas colunas fixas (Telefone1 e Telefone2) é uma solução limitada e arbitrária. Ela não garante a atomicidade para colaboradores com mais de dois telefones e cria colunas com valores nulos para quem tem menos. A 1FN não se satisfaz com um número fixo de colunas; a abordagem correta é a separação em tabela própria.

Alternativa E — ✅ Correta ⟵ GABARITO

Quebrar a tabela em duas — Colaborador (ColaboradorID, Nome) e Telefones (ColaboradorID, Telefone) — é a solução correta. Cada telefone ocupa uma linha distinta na tabela Telefones, e a coluna Telefone passa a ser atômica. A tabela Telefones referencia o colaborador por uma chave estrangeira (ColaboradorID), estabelecendo um relacionamento 1:N. Isso elimina o atributo multivalorado e coloca a estrutura na 1FN.

Gabarito: letra E