Pular para o conteudo

Resumo TI Banco de Dados: Segunda Forma Normal (2FN)

Com a tabela garantidamente em 1FN (valores atômicos, sem grupos repetitivos), começa a aplicação das formas normais que usam dependência funcional para eliminar anomalias. A primeira delas é a Segunda Forma Normal (2FN), que ataca diretamente a dependência parcial vista no resumo sobre dependências parciais e transitivas.

Neste resumo, você vai ver a definição formal de 2FN, retomar o exemplo de chave composta já usado na trilha para decompor a tabela corretamente e entender por que tabelas com chave simples nem precisam se preocupar com essa forma normal.

📲 Canal Oficial do Dicionário do Concurseiro no WhatsApp

Receba resumos, questões comentadas e novidades diretamente no seu celular!

👉 Acessar Canal no WhatsApp

💡 Conteúdo exclusivo para concurseiros. Totalmente gratuito!

🥈 Definição formal

Uma relação está na Segunda Forma Normal quando (1) já está em 1FN e (2) nenhum atributo não primo depende parcialmente de uma chave candidata — ou seja, todo atributo não primo depende da chave inteira (dependência total), nunca de apenas parte dela. As formas normais são cumulativas: para estar em 2FN, a relação precisa antes satisfazer 1FN.

🗄️ Retomando o exemplo: Pedido_Item com chave composta

O resumo sobre dependências parciais usou Pedido_Item(pedido_id, produto_id, quantidade, nome_produto, preco_produto), com chave candidata composta (pedido_id, produto_id). Ali, nome_produto e preco_produto dependem só de produto_id — uma dependência parcial que viola 2FN. quantidade, por depender da combinação inteira (pedido_id, produto_id), não tem problema.

✂️ Decomposição: separando o que depende de parte da chave

A correção é decompor a tabela em duas: Pedido_Item(pedido_id, produto_id, quantidade), mantendo só o atributo com dependência total, e Produto(produto_id, nome_produto, preco_produto), uma tabela nova cuja chave (agora só produto_id) determina totalmente os atributos que antes dependiam parcialmente. Depois da decomposição, é possível reconstruir a informação original fazendo o JOIN das duas tabelas por produto_id — decomposição sem perda de informação.

✅ Anomalias resolvidas

Com as tabelas separadas, cadastrar um produto novo não exige um pedido (resolve inserção); alterar o preço de um produto é uma única atualização, na tabela Produto (resolve atualização); excluir o último item de um pedido não apaga informação do produto, que continua existindo em sua própria tabela (resolve exclusão) — as mesmas três famílias de anomalias vistas no início da seção, agora resolvidas para o caso de dependência parcial.

🔑 Chave simples: 2FN “de graça”

Como dependência parcial só existe quando a chave candidata é composta (visto no resumo anterior), qualquer relação cuja única chave candidata seja um único atributo satisfaz 2FN automaticamente assim que satisfaz 1FN (o caso mais comum em prova) — não há “parte” de uma chave de um atributo só. É por isso que Funcionario(matricula, nome, departamento, gerente_departamento), com chave simples matricula, já está em 2FN — mas, como visto, ainda tem um problema diferente: dependência transitiva, que 2FN não resolve.

⚠️ Pegadinhas comuns

  • 2FN não elimina dependência transitiva — uma tabela pode estar perfeitamente em 2FN e ainda sofrer anomalias por dependência transitiva; isso é assunto da 3FN, no próximo resumo;
  • “Depende de parte da chave” só faz sentido para chave composta: a banca pode apresentar uma tabela com chave simples e perguntar se ela viola 2FN — a resposta correta é sempre negativa, independentemente de qualquer outro problema que a tabela tenha;
  • A decomposição precisa ser sem perda (lossless): as tabelas resultantes devem permitir reconstruir exatamente os dados originais via JOIN pela chave estrangeira — decompor errado pode gerar linhas fantasmas ou perder combinações válidas;
  • Nem toda dependência parcial é óbvia: a banca pode incluir um atributo que “parece” depender da chave inteira, mas, analisando com calma as regras de negócio do enunciado, depende só de parte dela.

🎯 Dica Final para a Prova

Primeiro cheque se a chave candidata é composta — se for simples, a tabela já está em 2FN e a questão está testando outra coisa. Se for composta, para cada atributo não primo pergunte: “esse valor mudaria se eu trocasse só uma parte da chave, mantendo a outra parte fixa?” Se sim, é dependência parcial e a tabela viola 2FN.

✓ Resolvida a dependência parcial, falta o segundo tipo de anomalia vista no resumo de dependências parciais e transitivas: a dependência transitiva, que a Terceira Forma Normal elimina — e que fecha, de vez, as três anomalias originais desta seção da trilha.


📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Terceira Forma Normal (3FN)


📘 2FN só existe como problema quando a chave é composta — e resolve exatamente a metade do que uma chave assim pode dar errado. Continue estudando!

Gostou deste conteúdo?

Favoritar

Comentários

Seja o primeiro a comentar.