Princípios da Segunda Forma Normal (2NF)

Uma tabela tá na segunda forma normal se:

1. Ela já tá na primeira forma normal (1NF).
2. Cada coluna que não faz parte da chave depende da chave primária inteira, e não só de um pedaço dela.

Se a chave primária tem vários campos (chave composta), nenhum atributo (coluna) que não faz parte da chave pode depender só de uma parte dessa chave. Ou seja, a 2NF elimina as dependências parciais.

Exemplo de violação da 2NF

Imagina que a gente tem uma tabela student_courses (Estudantes e Cursos), que guarda info dos estudantes, seus cursos e professores:

• student_id e course_id juntos formam a chave primária composta.
• Mas repara nas colunas course_name e instructor_name. Elas dependem só do course_id, não da dupla (student_id, course_id).

Aí está a dependência parcial! course_name e instructor_name dependem só de parte da chave composta (course_id). Isso quebra as regras da 2NF.

Como deixar a tabela em 2NF

Nosso objetivo é eliminar a dependência parcial, separando a tabela em duas. Assim a gente corta a redundância e melhora a consistência dos dados.

Vamos separar as infos dos cursos numa tabela courses:

A tabela principal fica assim:

Agora cada coluna depende da chave primária inteira. A gente separou os dados de um jeito lógico e eliminou a violação da 2NF.

A mágica de acabar com a redundância

Olha pra tabela antes da normalização. Na coluna instructor_name o nome "Lin" aparece várias vezes. Imagina isso numa base real com milhares de linhas? Separando as tabelas, a gente corta a redundância e diminui o risco de erro, tipo digitar "Lin" em vez de "Ling".

Exemplo da vida real

Pensa que você tá controlando pedidos de produtos. Você tem essa tabela order_items (pedidos e produtos), onde order_id e item_id formam a chave primária:

Viu que os preços e nomes dos produtos se repetem? Isso é sinal de violação da 2NF, porque item_name e price dependem só do item_id.

Pra deixar a tabela em 2NF, bora criar a tabela items:

E muda a tabela order_items, deixando só os IDs do pedido e do produto:

Agora os dados estão limpos igual código depois de um code review — zero redundância.

Desafio prático: tenta aí!

Imagina que você tem a tabela employee_projects, com info dos funcionários, projetos e gerentes dos projetos:

Tenta fazer:

1. Achar as dependências que quebram a 2NF.
2. Separar a tabela em duas, eliminando a violação.

Por que seguir a 2NF?

Pra que seguir a segunda forma normal (2NF)? Simples: pra não ter dados duplicados e evitar bagunça. Quando você tira as dependências parciais, as tabelas ficam mais limpas — sem info repetida, tipo o mesmo nome de professor em toda linha. Isso economiza espaço e evita inconsistências: mudou o nome num lugar, já tá certo em tudo.

Além disso, fazer query numa base assim é mais fácil: quando a estrutura faz sentido e os dados não tão espalhados em mil linhas, filtrar e agrupar fica mais rápido e confiável. Beleza, você vai ter que usar mais JOIN nos SQLs, porque tem mais tabelas. Mas é melhor um JOIN do que cem linhas com os mesmos nomes. Na real, normalizar quase sempre vale a pena.

Integrando com projetos reais

Saber 2NF vai te ajudar:

• Na modelagem do banco: evitando bagunça nas tabelas.
• Na entrevista: sempre pedem pra explicar ou normalizar tabelas.
• No trampo real: quando te pedirem pra otimizar um banco já existente, quebrando tabelas "monolíticas" em normalizadas.

A segunda forma normal (2NF) ajuda a eliminar dependências parciais em tabelas onde a chave primária é composta. A gente separa as tabelas em blocos lógicos, pra cada coluna depender só da chave inteira, não de um pedaço. Isso deixa o banco melhor, sem redundância e mais flexível. Pronto pra terceira forma normal? Bora lá!