Normalização: Da 1FN à 3FN Explicada de Forma Simples
A normalização de banco de dados reduz a redundância e melhora a integridade dos dados. Explicamos a Primeira, Segunda e Terceira Forma Normal com exemplos práticos que você pode aplicar nos seus próprios schemas.
Normalização é o processo de organizar o schema do seu banco de dados para reduzir redundância e prevenir anomalias nos dados. É um dos conceitos mais importantes no design de banco de dados relacional — e um dos mais mal compreendidos.
Por que Normalizar?
Imagine uma tabela onde cada linha de pedido contém diretamente o nome, e-mail e endereço do cliente. Se um cliente fizer 50 pedidos, seu nome e e-mail ficam armazenados 50 vezes. Quando ele muda o e-mail, você precisa atualizar 50 linhas. Se perder uma, seus dados ficam inconsistentes.
A normalização resolve isso dividindo os dados em tabelas separadas conectadas por chaves estrangeiras. Os dados do cliente ficam em um único lugar, e os pedidos simplesmente referenciam o cliente pelo ID.
Primeira Forma Normal (1FN)
Uma tabela está na 1FN quando cada coluna contém apenas valores atômicos (indivisíveis), e não há grupos repetidos. Isso significa sem arrays, sem listas separadas por vírgulas e sem padrões de "coluna1, coluna2, coluna3".
Antes da 1FN: Uma tabela contacts com uma coluna phone_numbers contendo "555-1234, 555-5678". Depois da 1FN: Uma tabela separada phone_numbers com uma linha por número de telefone, vinculada a contacts por uma chave estrangeira.
A regra é simples: cada coluna deve armazenar um único valor. Se você precisar de múltiplos valores, crie uma tabela separada.
Segunda Forma Normal (2FN)
Uma tabela está na 2FN quando já está na 1FN e cada coluna não-chave depende da chave primária inteira, não apenas de parte dela. Isso se aplica principalmente a tabelas com chaves primárias compostas.
Exemplo: Uma tabela order_items com uma chave composta de (order_id, product_id) e uma coluna product_name. O nome do produto depende apenas de product_id, não da chave composta completa. Para corrigir, mova product_name para a tabela products.
Na prática, se você usar chaves primárias substitutas de coluna única (como IDs auto-incrementais), é menos provável que viole a 2FN. Mas ainda é importante entender o princípio.
Terceira Forma Normal (3FN)
Uma tabela está na 3FN quando está na 2FN e cada coluna não-chave depende diretamente da chave primária, não de outra coluna não-chave. Isso elimina as dependências transitivas.
Exemplo: Uma tabela employees com department_id, department_name e department_location. O nome e a localização do departamento dependem de department_id, não do funcionário. Solução: crie uma tabela departments e mantenha apenas department_id em employees.
Quando Parar de Normalizar
Existem formas normais mais altas (BCNF, 4FN, 5FN), mas a 3FN é suficiente para a grande maioria das aplicações. Na verdade, às vezes você vai desnormalizar intencionalmente por questões de performance — armazenando um total_amount em um pedido em vez de calculá-lo a partir dos itens toda vez.
A chave é começar normalizado e desnormalizar deliberadamente quando você tiver uma necessidade de performance mensurável. Nunca comece desnormalizado e espere corrigir depois.
Visualizando a Normalização
Diagramas ER são a melhor forma de identificar problemas de normalização. Quando você vê uma tabela com colunas demais, ou colunas que parecem pertencer a uma entidade diferente, é um sinal de que a tabela precisa ser dividida. O ER Flow torna esse processo visual e iterativo — arraste colunas para novas tabelas, defina relacionamentos e veja o resultado instantaneamente.