Normalização tem fama de assunto chato e decoreba — 1FN, 2FN, 3FN, formas que ninguém lembra na hora. Mas a ideia por trás é simples e prática: organizar os dados para que cada fato fique guardado em um único lugar. Quando você entende o problema que cada forma resolve, não precisa decorar nada.
O problema: dado duplicado gera anomalias
Imagine uma única tabela registrando pedidos com o nome e o telefone do cliente repetidos em cada linha. Três coisas dão errado:
- Anomalia de atualização — o cliente muda de telefone e você precisa alterar dezenas de linhas; esquece uma e os dados ficam inconsistentes.
- Anomalia de inserção — você não consegue cadastrar um cliente novo sem que ele tenha feito um pedido.
- Anomalia de exclusão — apagar o último pedido de um cliente apaga o cliente junto.
Normalizar é eliminar essas redundâncias dividindo a tabela em outras menores e bem definidas.
1FN: valores atômicos
A Primeira Forma Normal exige que cada célula guarde um único valor. Nada de uma coluna telefones com "1199, 1188" separados por vírgula, nem colunas repetidas como produto1, produto2. Se você tem uma lista dentro de uma célula, ela vira linhas em uma tabela própria.
2FN: dependência da chave inteira
A Segunda Forma Normal só importa quando a chave primária é composta (duas ou mais colunas). Ela diz: todo atributo não-chave deve depender da chave inteira, não de parte dela.
Numa tabela de itens de pedido com chave (pedido_id, produto_id), o nome_produto depende só do produto_id — parte da chave. Isso viola a 2FN. A solução é mover o nome para uma tabela de produtos.
3FN: sem dependência transitiva
A Terceira Forma Normal ataca a dependência transitiva: um atributo não-chave que depende de outro atributo não-chave. Se na tabela de clientes você guarda cidade e estado, e o estado é determinado pela cidade, há uma dependência transitiva. Cidade vira uma tabela própria.
Um exemplo evoluindo
Veja como uma tabela bagunçada se transforma:
| Antes (tudo junto) | Depois (3FN) |
|---|---|
pedidos: id, cliente_nome, cliente_tel, produtos (lista), produto_preco | clientes: id, nome, tel |
| Dados de cliente e produto repetidos em cada linha | produtos: id, nome, preco |
| Anomalias em toda atualização | itens_pedido: pedido_id, produto_id, qtd |
Cada fato — o telefone do cliente, o preço do produto — agora vive em exatamente um lugar.
Não decore "2FN é dependência parcial". Pergunte: "este dado está repetido sem motivo? Se eu mudar ele, vou ter que mudar em vários lugares?" Se sim, ainda falta normalizar.
Quando desnormalizar de propósito
Normalização é ótima para escrita e integridade, mas pode custar caro na leitura: para montar um relatório, você junta muitas tabelas com JOINs. Em cenários de leitura intensa, às vezes vale desnormalizar de propósito — duplicar dados controladamente para evitar joins e ganhar velocidade. É uma decisão consciente de trade-off, não preguiça. Modelos analíticos, como veremos em modelagem dimensional, abraçam essa ideia.
Conclusão
As três primeiras formas normais resolvem, uma a uma, fontes específicas de redundância: valores não-atômicos, dependência parcial e dependência transitiva. Entenda o problema de cada uma e você normaliza por raciocínio. É comum em entrevista pedir para identificar qual forma uma tabela viola — e no dia a dia, saber quando manter o esquema normalizado e quando relaxar de propósito é o que distingue um bom projeto de dados.
Normalization has a reputation as a boring subject full of memorization — 1NF, 2NF, 3NF, forms nobody remembers on the spot. But the idea behind it is simple and practical: organize data so that each fact is stored in a single place. Once you understand the problem each form solves, you don't need to memorize anything.
The problem: duplicated data causes anomalies
Imagine a single table recording orders with the customer's name and phone repeated on every row. Three things go wrong:
- Update anomaly — the customer changes phone number and you have to change dozens of rows; miss one and the data becomes inconsistent.
- Insertion anomaly — you can't register a new customer unless they've placed an order.
- Deletion anomaly — deleting a customer's last order deletes the customer along with it.
To normalize is to eliminate these redundancies by splitting the table into smaller, well-defined ones.
1NF: atomic values
The First Normal Form requires each cell to hold a single value. No telefones column with "1199, 1188" separated by commas, and no repeated columns like produto1, produto2. If you have a list inside a cell, it becomes rows in its own table.
2NF: dependence on the whole key
The Second Normal Form only matters when the primary key is composite (two or more columns). It says: every non-key attribute must depend on the whole key, not on part of it.
In an order-items table with key (pedido_id, produto_id), nome_produto depends only on produto_id — part of the key. That violates 2NF. The fix is to move the name to a products table.
3NF: no transitive dependency
The Third Normal Form tackles transitive dependency: a non-key attribute that depends on another non-key attribute. If in the customers table you store cidade (city) and estado (state), and the state is determined by the city, there's a transitive dependency. City becomes its own table.
An evolving example
See how a messy table gets transformed:
| Before (everything together) | After (3NF) |
|---|---|
pedidos: id, cliente_nome, cliente_tel, produtos (list), produto_preco | clientes: id, nome, tel |
| Customer and product data repeated on every row | produtos: id, nome, preco |
| Anomalies on every update | itens_pedido: pedido_id, produto_id, qtd |
Each fact — the customer's phone, the product's price — now lives in exactly one place.
Don't memorize "2NF is partial dependency". Ask: "is this data repeated for no reason? If I change it, will I have to change it in several places?" If so, it still needs normalizing.
When to denormalize on purpose
Normalization is great for writes and integrity, but it can be costly on reads: to build a report, you join many tables with JOINs. In read-heavy scenarios, it's sometimes worth denormalizing on purpose — duplicating data in a controlled way to avoid joins and gain speed. It's a conscious trade-off decision, not laziness. Analytical models, as we'll see in dimensional modeling, embrace this idea.
Conclusion
The first three normal forms solve, one by one, specific sources of redundancy: non-atomic values, partial dependency and transitive dependency. Understand the problem behind each one and you normalize by reasoning. In interviews it's common to be asked which form a table violates — and day to day, knowing when to keep the schema normalized and when to relax it on purpose is what distinguishes a good data design.