Princípios da Terceira Forma Normal (3NF)

A terceira forma normal (3NF) é mais um passo pra deixar nossos dados organizados de verdade. Resumindo, uma tabela está em 3NF se:

1. Ela já está na segunda forma normal (2NF).
2. Todos os atributos que não são chave dependem só da chave primária e de mais nada (nada de dependências transitivas!).

Ou seja, a 3NF exige que todos os dados da tabela estejam ligados diretamente à chave primária e não dependam de outros atributos que não são chave.

Dependência transitiva rola quando o atributo A depende do atributo B, e o atributo B depende do atributo C, criando uma corrente de dependências A → B → C. Por exemplo, "Funcionário" depende do "Departamento", e "Departamento" depende da "Localização". Então, "Funcionário" depende transitivamente da "Localização".

Exemplo de violação da 3NF

Imagina que a gente tem uma tabela employees que guarda dados dos funcionários:

Aqui:

• employee_id — chave primária.
• department e department_manager — atributos que não são chave.

À primeira vista parece tudo certo, mas se olhar com calma, tem um problema: department_manager depende não de employee_id, mas de department. Ou seja, temos uma dependência transitiva: employee_id → department → department_manager.

Problemas que podem aparecer

Se a gente mudar o nome do gerente do departamento ("Finance"), vai ter que atualizar todas as linhas onde esse departamento aparece. Se esquecer de atualizar alguma, os dados ficam inconsistentes. É dor de cabeça que dá pra evitar.

Como deixar a tabela em 3NF

Pra acabar com as dependências transitivas, vamos dividir a tabela em duas: uma pra guardar os funcionários e outra pros departamentos.

Tabela employees

Tabela departments

Agora ficou tudo organizado, cada tabela faz seu papel:

1. A tabela employees guarda os dados dos funcionários.
2. A tabela departments guarda os dados dos departamentos e seus gerentes.

Se o gerente do departamento mudar, só precisa atualizar uma linha na tabela departments, não em todos os funcionários.

Como saber se a tabela viola a 3NF?

Pra sacar se a tabela tá violando a 3NF, olha só:

1. Tem dependências transitivas na tabela? Tipo, atributo A depende do atributo B, que depende do atributo C.
2. Todos os atributos que não são chave dependem direto da chave primária? Se algum depende de outro atributo que não é chave, a tabela não tá em 3NF.

Exemplo prático: loja

Olha a tabela sales, que tem os dados das vendas:

Aqui dá pra ver fácil a redundância: o preço do produto se repete em cada venda. Se o preço mudar, os dados já ficam inconsistentes.

Pra resolver a violação da 3NF, vamos dividir em duas tabelas:

1. A tabela sales vai guardar as vendas.
2. A tabela products — os produtos e seus preços.

Tabela sales

Tabela products

Agora, se o preço do produto mudar, é só atualizar uma linha na tabela products e os dados continuam certinhos.

Exercício prático

Olha só esse desafio: você tem a tabela students_courses desse jeito:

Divide essa tabela pra ela ficar em 3NF. Dica: você vai precisar criar três tabelas (students, courses, teachers) e ligar elas do jeito certo.

Por que é importante seguir a 3NF?

Por que se preocupar com a terceira forma normal (3NF)? Porque ela facilita muito a vida. Quando as tabelas estão em 3NF, os dados ficam mais organizados — nada de duplicação desnecessária, então é menos chance de dar ruim sem querer. Atualizar fica mais rápido e fácil, já que tudo tá num lugar só, não espalhado em várias linhas.

Além disso, a estrutura do banco fica mais flexível. Quer adicionar um campo novo ou mudar um antigo? Não precisa refazer tudo.

Mas, como tudo na vida, tem um porém: normalizar demais pode virar um monte de tabelinha e consultas cheias de JOIN. Às vezes isso pode até deixar mais lento. Então o segredo é equilíbrio. Onde precisa, normaliza; onde dá pra deixar um pouco de redundância, não tem problema.

Na sequência, vamos aprofundar mais: aprender a criar relações entre tabelas e montar bancos que sejam práticos e confiáveis. Bora lá, rumo a um design de banco de dados top!