Normalização: 1FN, 2FN e 3FN passo a passo com tabela

Normalizar é organizar as tabelas de um banco relacional para reduzir repetição de dados e evitar anomalias na inclusão, na alteração e na exclusão. A prova cobra as definições das formas normais e, principalmente, a habilidade de enxergar uma dependência e dizer qual forma ela viola. Este guia faz o processo completo em uma tabela de pedidos fictícia, e a decomposição foi conferida em um banco de teste. A visão geral do tema está em bancos de dados: chaves, normalização, SQL e transações; aqui o foco é o passo a passo.

Dependência funcional: a ferramenta central

Dizemos que A determina B (A → B) quando cada valor de A está associado a exatamente um valor de B. Exemplo: o código do cliente determina o nome do cliente. A chave de uma tabela é o conjunto mínimo de colunas que determina todas as demais.

Três tipos de dependência importam:

Total: o atributo depende da chave inteira.
Parcial: o atributo depende de apenas parte de uma chave composta.
Transitiva: o atributo depende de outro atributo que não é chave (A → B e B → C, com A chave).

A tabela de partida

Tabela pedido_bruto, com chave composta (num_pedido, cod_item):

num_pedido	cod_item	nome_item	qtd	cod_cli	nome_cli	cidade_cli	uf
1	10	Caneta	5	100	Ana	Brasilia	DF
1	20	Papel	2	100	Ana	Brasilia	DF
2	10	Caneta	3	200	Bruno	Goiania	GO
3	30	Grampo	1	100	Ana	Brasilia	DF

Os dados são inventados. Os problemas já saltam aos olhos: os dados da cliente Ana aparecem em três linhas, e “Caneta” em duas.

Anomalias demonstradas

De alteração: ao mudar a cidade de Ana em apenas uma linha (a do pedido 1, item 10), o banco de teste ficou com duas cidades para o mesmo cliente 100: Taguatinga e Brasilia. Os dados ficaram inconsistentes.
De inclusão: para cadastrar um item novo ainda sem pedido, seria preciso inventar um número de pedido.
De exclusão: apagar o único pedido do cliente 200 apagaria também o cadastro do Bruno.

Primeira forma normal (1FN)

Uma tabela está na 1FN quando todos os atributos são atômicos (indivisíveis) e não há grupos repetidos: cada célula guarda um único valor.

Violação típica: uma coluna telefones com “6199999-0001, 6199999-0002”. Correção: uma linha por telefone, ou uma tabela telefone ligada ao cliente. Nossa tabela de pedidos já está na 1FN, pois cada célula tem um valor só e existe uma chave (num_pedido, cod_item).

Segunda forma normal (2FN)

Está na 2FN quando está na 1FN e nenhum atributo não chave depende de apenas parte da chave. A 2FN só faz sentido quando a chave é composta; com chave simples, a tabela em 1FN já está em 2FN.

Dependências da tabela:

Dependência	Tipo
(num_pedido, cod_item) → qtd	total (a quantidade é daquele item naquele pedido)
cod_item → nome_item	parcial: depende só de cod_item
num_pedido → cod_cli, nome_cli, cidade_cli, uf	parcial: depende só de num_pedido

Para eliminar as dependências parciais, separam-se as tabelas:

Tabela	Colunas	Chave
item	cod_item, nome_item	cod_item
pedido	num_pedido, cod_cli, nome_cli, cidade_cli, uf	num_pedido
item_pedido	num_pedido, cod_item, qtd	(num_pedido, cod_item)

Terceira forma normal (3FN)

Está na 3FN quando está na 2FN e nenhum atributo não chave depende de outro atributo não chave (sem dependência transitiva).

Na tabela pedido: num_pedido → cod_cli, e cod_cli → nome_cli, cidade_cli e uf. Então nome, cidade e UF dependem do pedido apenas por intermédio do cliente: transitividade. Solução, separar o cliente:

Tabela	Colunas	Chave
cliente	cod_cli, nome_cli, cidade_cli, uf	cod_cli
pedido	num_pedido, cod_cli (chave estrangeira)	num_pedido

Resultado final, na 3FN: item, cliente, pedido e item_pedido. No teste, as tabelas ficaram assim:

item
10	Caneta
20	Papel
30	Grampo

cliente ficou com duas linhas (100, Ana, Brasilia, DF e 200, Bruno, Goiania, GO); pedido com (1, 100), (2, 200) e (3, 100); item_pedido com (1, 10, 5), (1, 20, 2), (2, 10, 3) e (3, 30, 1). Agora a cidade de Ana mora em um único lugar: a alteração é feita uma vez.

Aqui entra uma ressalva: cidade e UF aparecem juntas como descrição do endereço do cliente. Não consideramos “cidade determina UF”, porque nomes de cidade se repetem em estados diferentes; decisão assim depende da regra de negócio, e a prova deve informar as dependências ao pedir normalização.

Conferindo que nada se perdeu

Uma boa decomposição é sem perdas: juntando as tabelas, recupera-se exatamente a original. No teste, a junção de pedido, item_pedido, item e cliente pelas chaves reproduziu as mesmas quatro linhas da tabela de partida, sem linhas a mais nem a menos. Se a decomposição fosse feita por colunas sem ligação pela chave, a junção traria linhas falsas.

Frase mnemônica das formas normais

Para chaves simples, vale lembrar que cada atributo deve depender “da chave, de toda a chave e nada além da chave”: a 1FN trata de valores atômicos, a 2FN de toda a chave (sem dependência parcial) e a 3FN de nada além da chave (sem dependência transitiva).

E depois da 3FN?

A forma normal de Boyce-Codd (FNBC) é uma 3FN mais rigorosa: todo determinante de uma dependência funcional deve ser chave candidata. Ela só difere da 3FN em casos com várias chaves candidatas sobrepostas. A 4FN trata dependências multivaloradas. Em projetos reais, às vezes se desnormaliza de propósito, por desempenho de leitura, aceitando a redundância controlada.

Passo a passo para a prova

Identifique a chave (simples ou composta).
Liste as dependências funcionais dadas ou deduzidas.
1FN: há valores não atômicos ou grupos repetidos?
2FN: há atributo dependendo de parte da chave composta?
3FN: há atributo não chave dependendo de outro não chave?
Separe as tabelas e preserve as chaves estrangeiras.

Erros comuns

Dizer que a 2FN trata de dependência transitiva (é a 3FN).
Procurar dependência parcial em tabela de chave simples.
Esquecer que a normalização não pode perder informação.
Achar que normalizar sempre melhora o desempenho.
Normalizar sem as dependências informadas, supondo regras que o enunciado não deu.

Fontes e atualização

Não há norma oficial brasileira sobre normalização; o conteúdo segue a teoria clássica do modelo relacional. A decomposição do exemplo foi executada em um banco de teste. Definições variam um pouco entre autores (por exemplo, o tratamento de chaves candidatas): confira a bibliografia do edital.

Próximos passos

Modele antes de normalizar em modelagem de dados: MER, cardinalidade e modelo relacional.
Consulte os dados em SQL JOIN: INNER, LEFT, RIGHT, FULL e CROSS.
Proteja a integridade com SQL: DDL, DML, DCL e TCL.