Normalização de banco de dados: da 1FN à 5FN e FNBC

Normalização é um processo de organização das tabelas de um banco de dados relacional. Seu objetivo é representar cada fato no lugar adequado, reduzir repetições desnecessárias e evitar inconsistências durante inserções, alterações e exclusões. As formas mais estudadas são 1FN, 2FN, 3FN, FNBC, 4FN e 5FN; cada etapa trata um tipo mais específico de dependência entre os dados.

O problema de guardar tudo em uma tabela

Considere uma planilha chamada vendas com número do pedido, data, cliente, telefone, produto, preço e quantidade. Se um pedido possuir três produtos, os dados do cliente e do pedido serão repetidos três vezes. Essa repetição cria riscos:

• Anomalia de atualização: o telefone do cliente é alterado em uma linha e permanece antigo em outras.
• Anomalia de inserção: não conseguimos cadastrar um produto antes que exista um pedido.
• Anomalia de exclusão: ao apagar o último pedido de um cliente, podemos perder também seus dados cadastrais.

O problema não é simplesmente “ter dados repetidos”. Algumas repetições são inevitáveis, como a chave estrangeira presente em vários pedidos. O problema é armazenar o mesmo fato independente em muitos lugares.

Dependência funcional: a pergunta central

Dizemos que um atributo depende funcionalmente de outro quando um valor determina um único valor correspondente. Se cada cliente_id identifica exatamente um cliente, então ele determina nome e telefone:

cliente_id → cliente_nome, cliente_telefone

Da mesma forma, produto_id determina descrição e preço cadastrado. Identificar essas dependências ajuda a descobrir quais atributos pertencem juntos. Antes de normalizar, é importante ter uma chave que identifique cada registro.

Primeira Forma Normal — 1FN

Uma tabela em 1FN trabalha com valores atômicos dentro de cada coluna e não mantém grupos repetitivos. Isso significa que uma célula não deve guardar uma lista como “teclado, mouse, monitor” nem criar colunas produto1, produto2 e produto3.

Para representar vários produtos por pedido, criamos uma linha por combinação de pedido e produto. Essa tabela intermediária pode ter uma chave composta formada por pedido_id e produto_id.

itens_pedido (
  pedido_id,
  produto_id,
  quantidade,
  preco_venda
)

O preço da venda é mantido no item porque registra um fato histórico daquela negociação; ele pode ser diferente do preço atual do cadastro do produto.

Segunda Forma Normal — 2FN

Para estar em 2FN, a tabela precisa estar em 1FN e cada atributo que não pertence à chave deve depender da chave completa. Essa análise é especialmente importante quando a chave é composta.

Na tabela itens_pedido, imagine que também fossem guardados produto_nome e pedido_data. A chave seria (pedido_id, produto_id), mas:

• produto_nome depende somente de produto_id;
• pedido_data depende somente de pedido_id;
• quantidade depende da combinação de pedido e produto.

As dependências parciais indicam que os atributos devem ser separados:

pedidos (id, data, cliente_id)
produtos (id, nome, preco_atual)
itens_pedido (pedido_id, produto_id, quantidade, preco_venda)

Agora cada tabela descreve um conceito. Os itens continuam ligados aos pedidos e produtos por chaves estrangeiras, sem copiar seus dados descritivos.

Terceira Forma Normal — 3FN

Para chegar à 3FN, a estrutura deve estar em 2FN e os atributos não-chave não devem depender de outros atributos não-chave. Em linguagem direta: cada coluna descritiva deve depender da chave, e não de uma informação intermediária.

Suponha esta tabela:

clientes (
  id,
  nome,
  cidade_id,
  cidade_nome,
  estado_sigla
)

cidade_nome e estado_sigla não descrevem diretamente o cliente; eles são determinados por cidade_id. Essa é uma dependência transitiva. Uma possível separação é:

clientes (id, nome, cidade_id)
cidades (id, nome, estado_sigla)

Se o sistema precisar guardar mais informações sobre estados e evitar a repetição da sigla em cidades, o projeto ainda pode criar estados. A normalização acompanha as regras reais do domínio, não uma divisão automática de toda coluna.

Resultado final do exemplo

Separar as tabelas não impede relatórios completos. Quando for preciso apresentar nome do cliente, pedido e produto juntos, usamos SQL JOIN para recombinar os dados. A estrutura normalizada melhora a integridade; a consulta oferece a visão necessária.

Exemplo de implementação no PostgreSQL

CREATE TABLE clientes (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  nome varchar(120) NOT NULL
);

CREATE TABLE pedidos (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  cliente_id integer NOT NULL REFERENCES clientes(id),
  data_pedido date NOT NULL
);

CREATE TABLE produtos (
  id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  nome varchar(120) NOT NULL,
  preco_atual numeric(10,2) NOT NULL
);

CREATE TABLE itens_pedido (
  pedido_id integer REFERENCES pedidos(id),
  produto_id integer REFERENCES produtos(id),
  quantidade integer NOT NULL CHECK (quantidade > 0),
  preco_venda numeric(10,2) NOT NULL,
  PRIMARY KEY (pedido_id, produto_id)
);

As restrições PRIMARY KEY, REFERENCES, NOT NULL e CHECK ajudam o banco a proteger as regras que o modelo definiu.

Forma Normal de Boyce-Codd — FNBC ou BCNF

A Forma Normal de Boyce-Codd fortalece a 3FN. Em uma tabela na FNBC, sempre que um conjunto de atributos determina outro atributo por uma dependência funcional não trivial, esse conjunto determinante precisa ser uma superchave. Em termos simples: somente uma chave pode determinar fatos dentro daquela relação.

Considere a relação:

alocacoes (aluno, disciplina, professor)

Admita duas regras: cada aluno possui um único professor por disciplina e cada professor ensina somente uma disciplina. Assim, temos:

(aluno, disciplina) → professor
professor → disciplina

A relação pode satisfazer a 3FN porque disciplina participa de uma chave candidata. Porém, ela viola a FNBC: professor determina disciplina, mas professor sozinho não identifica uma alocação completa.

Uma decomposição possível é:

professores_disciplinas (professor, disciplina)
alunos_professores (aluno, professor)

Quarta Forma Normal — 4FN

A 4FN trata dependências multivaloradas independentes. Elas aparecem quando uma entidade possui dois ou mais conjuntos de valores múltiplos que não dependem uns dos outros.

Imagine uma tabela que registra idiomas e habilidades de uma pessoa:

pessoa_conhecimentos (pessoa, idioma, habilidade)

Se Ana fala português e inglês, além de conhecer SQL e C#, a tabela precisaria registrar quatro combinações: português–SQL, português–C#, inglês–SQL e inglês–C#. Essas combinações não representam quatro fatos diferentes; existem apenas dois idiomas e duas habilidades independentes.

A solução em 4FN é separar as relações:

pessoa_idiomas (pessoa, idioma)
pessoa_habilidades (pessoa, habilidade)

Agora adicionar um novo idioma não exige repeti-lo para cada habilidade. A decomposição é apropriada porque os dois conjuntos são realmente independentes. Se determinada habilidade dependesse do idioma — por exemplo, “fluência para tradução técnica em inglês” — a regra do domínio seria diferente.

Quinta Forma Normal — 5FN

A 5FN, também chamada forma normal de projeção-junção, trata dependências de junção. Ela procura relações que podem ser decompostas em três ou mais tabelas menores e depois reconstruídas por JOIN sem gerar combinações falsas nem perder fatos.

O exemplo clássico envolve fornecedor, peça e projeto:

fornecimentos (fornecedor, peca, projeto)

Suponha que uma combinação tripla seja válida quando três relações independentes forem verdadeiras: o fornecedor fornece a peça, o fornecedor atende ao projeto e a peça é usada no projeto. Nesse cenário específico, podemos decompor:

fornecedor_peca (fornecedor, peca)
fornecedor_projeto (fornecedor, projeto)
peca_projeto (peca, projeto)

A junção das três relações deve reconstruir exatamente os fornecimentos permitidos. Se ela criar uma combinação que nunca existiu, a decomposição não é sem perdas e não pode substituir a relação original.

E a Sexta Forma Normal e a DKNF?

Sexta Forma Normal — 6FN

A 6FN leva a decomposição a relações que não podem ser divididas novamente de forma não trivial sem perder informação. Ela aparece sobretudo em modelagem temporal, na qual atributos de uma mesma entidade podem mudar em períodos diferentes. Em vez de manter nome, endereço e cargo com um único intervalo de validade, o projeto pode registrar cada fato temporal separadamente.

É uma técnica especializada. Em sistemas transacionais comuns, decompor até esse nível pode aumentar muito a quantidade de tabelas e junções sem trazer benefício proporcional.

Forma Normal Domínio-Chave — DKNF

Na DKNF, todas as restrições da relação deveriam resultar apenas das definições de domínio e de chave. É um objetivo teórico elegante, mas muitas regras de negócio — limites condicionais, dependências entre períodos e exceções operacionais — não cabem apenas nessas duas categorias. Por isso, a DKNF é mais útil como referência conceitual do que como meta obrigatória.

Mapa das formas normais

Até onde devemos normalizar?

Em projetos transacionais, 3FN e FNBC costumam oferecer uma base forte. A 4FN e a 5FN tornam-se importantes quando os requisitos revelam dependências multivaloradas ou de junção. Não é necessário transformar toda tabela mecanicamente até a forma mais alta; é necessário identificar as dependências que realmente existem e preservar os dados em uma decomposição sem perdas.

Uma forma normal mais alta pressupõe as anteriores: uma relação em 5FN também deve satisfazer 4FN, FNBC, 3FN, 2FN e 1FN. Ainda assim, “mais alta” não significa automaticamente “melhor para qualquer sistema”. Clareza, integridade, preservação das dependências e consultas necessárias precisam ser avaliadas em conjunto.

Normalizar sempre melhora o desempenho?

Normalização é principalmente uma decisão de integridade e clareza. Mais tabelas podem exigir mais junções em determinadas consultas. Sistemas analíticos ou situações de desempenho comprovado podem adotar desnormalização controlada, mas isso cria duplicação consciente e exige mecanismos de consistência. Não desnormalize apenas para evitar aprender JOIN; primeiro meça o problema real.

Perguntas frequentes