DevPath · Aprenda a programar ESPTEN

Design, normalização e modificação de dados

Normalização: 1FN, 2FN e 3FN

Por que normalizar?

A normalização é o processo de organizar as colunas e tabelas para eliminar a redundância (dados repetidos) e evitar as anomalias:

Avança-se por formas normais cumulativas: para estar na 3FN é preciso cumprir antes a 1FN e a 2FN.

Primeira forma normal (1FN)

Uma tabela está na 1FN se:

❌ Não 1FN ✅ 1FN
telefones = '600, 611' uma linha por telefone em uma tabela à parte

Segunda forma normal (2FN)

Uma tabela está na 2FN se está na 1FN e, além disso, nenhum atributo não chave depende somente de uma parte de uma chave primária composta (não há dependências parciais).

Só é relevante quando a PK é composta. Exemplo: em linha_pedido(pedido_id, produto_id, nome_produto), o nome_produto depende somente de produto_id, não da chave completa → viola a 2FN. A solução: mover nome_produto para a tabela produtos.

Terceira forma normal (3FN)

Uma tabela está na 3FN se está na 2FN e nenhum atributo não chave depende de outro atributo não chave (não há dependências transitivas).

Exemplo que viola a 3FN:

pedido_id cliente_id cliente_cidade

Aqui cliente_cidade depende de cliente_id (não da PK pedido_id). Se Ana muda de cidade é preciso atualizar todos os seus pedidos. A solução é separar: a cidade vive na tabela clientes, e pedidos só guarda cliente_id.

Em resumo, 3FN = "cada atributo não chave depende da chave, de toda a chave e de nada além da chave". É o objetivo razoável para a maioria dos esquemas de aplicação.

Coloque isto em prática

O DevPath é um curso prático: aqui você lê a teoria; no app você a coloca em prática com exercícios que rodam de verdade, offline.

Comece grátis no app →
← Design relacional: chaves e relaçõesModificar dados: INSERT, UPDATE, DELETE e restrições →