Modelagem e normalização

O problema: o modelo dura mais que o código

O código de uma aplicação é reescrito, refatorado, trocado de framework. As tabelas ficam. Mudar uma coluna numa tabela com milhões de linhas exige uma migração cuidadosa, e os dados ruins que entraram por um modelo frouxo continuam lá, esperando a próxima consulta que não sabe tratá-los.

A modelagem relacional decide três coisas: quais tabelas existem, quais colunas cada uma tem e como elas se ligam.

Tabelas, linhas e chaves

Cada tabela representa um tipo de coisa: clientes, produtos, pedidos. Cada linha é uma ocorrência. E cada tabela tem uma chave primária, a coluna (ou o conjunto de colunas) que identifica a linha sem ambiguidade.

As ligações entre tabelas são feitas por chaves estrangeiras: a coluna pedidos.cliente_id aponta para clientes.id, e o banco recusa um pedido de um cliente que não existe.

Os relacionamentos têm três formas:

A tabela do meio, nos muitos para muitos, costuma ganhar vida própria: itens_pedido não guarda só os dois identificadores, mas a quantidade e o preço daquele item naquele pedido.

Normalização: cada fato num lugar só

Imagine uma tabela de pedidos que guarda, em cada linha, o nome e o e-mail do cliente:

O nome da Ana aparece três vezes, e já está diferente numa delas. Qual é o certo? Para mudar o e-mail dela, é preciso atualizar todas as linhas, e uma atualização que esquece uma linha deixa o banco contraditório. Esses são os problemas de atualização que a normalização evita.

Normalizar é organizar as tabelas para que cada fato fique num lugar só. As formas normais formalizam isso. Na prática, as três primeiras resolvem quase tudo:

A frase que resume as três: cada coluna depende da chave, da chave inteira e de nada além da chave.

Desnormalizar de propósito

Normalizar não é dogma. Às vezes, repetir um dado é exatamente o certo:

• O preço na hora da compra. itens_pedido.preco_unitario repete o preço do produto, mas não é redundância: o preço do produto muda amanhã, e o pedido de hoje precisa continuar com o valor cobrado. São dois fatos diferentes, que hoje coincidem.
• Totais para leitura rápida. Guardar pedidos.total evita somar os itens a cada listagem, ao custo de manter o total certo sempre que um item muda.
• Cópias para relatórios. Tabelas desnormalizadas, montadas a partir das normalizadas, para consultas analíticas.

A diferença entre desnormalizar e bagunçar é saber qual é a fonte da verdade e quem mantém a cópia atualizada.

As regras ficam no banco

As restrições do banco (NOT NULL, UNIQUE, CHECK, FOREIGN KEY) garantem as regras para qualquer código que escreva na tabela: a aplicação de hoje, o script de amanhã, a correção manual feita às pressas. A tentação é conferir na aplicação ("já existe um cliente com esse e-mail?") e pular a restrição. Medimos o que acontece com 20 cadastros simultâneos do mesmo e-mail, escrito ora em minúsculas, ora com maiúsculas, todos passando pela conferência antes de gravar:

Com a conferência sozinha, 18 dos 20 pedidos consultaram a tabela antes de qualquer outro gravar, não acharam nada e gravaram. Com o índice único, o banco recusou 16 e a conferência barrou 3. A conferência na aplicação continua útil para dar uma mensagem amigável, mas quem garante a regra é o banco. O índice em lower(email) também resolve a diferença entre Ana@Exemplo.com e ana@exemplo.com, que um UNIQUE (email) simples deixaria passar.

Os tipos certos

Três escolhas de tipo que custam caro quando erradas, medidas no Postgres 18:

Dinheiro não é ponto flutuante.

Ponto flutuante representa números em base 2, e 0,1 não tem representação exata. Os erros aparecem em somas e comparações. Para dinheiro, use numeric(12, 2) ou um inteiro em centavos.

Datas precisam do fuso. Gravamos now() numa coluna timestamp e noutra timestamptz, com a sessão em America/Sao_Paulo, e lemos com a sessão em UTC. A coluna timestamptz mostrou 04:48 em UTC, o instante correto. A coluna timestamp mostrou 01:48, o horário de Brasília guardado sem fuso, agora interpretado como se fosse UTC: três horas de erro, sem nenhum aviso. Use timestamptz.

O tipo da chave primária pesa. Inserimos 2 milhões de linhas em três tabelas iguais, mudando só a chave:

O UUID v4 é aleatório: cada linha nova cai num ponto qualquer do índice, que se divide em páginas meio vazias. O UUID v7 começa pelo carimbo de tempo, e as linhas novas vão para o fim do índice, como num sequencial. Os números são de uma inserção em lote numa máquina de desenvolvimento, e servem para comparar os três tipos entre si, não como medida absoluta.

A chave estrangeira precisa de índice

O Postgres cria um índice para a chave primária e para UNIQUE, mas não para a coluna da chave estrangeira. Isso pesa ao apagar ou atualizar a linha apontada: para cada cliente apagado, o banco precisa achar os pedidos dele.

Com 100 mil clientes e 2 milhões de pedidos, apagar 100 clientes (com ON DELETE CASCADE) levou:

Sem o índice, cada cliente apagado gerou uma varredura completa da tabela de pedidos. O mesmo índice serve para a consulta mais comum desse modelo: "os pedidos deste cliente".

Por que isso importa quando a IA escreve o código

Um assistente que cria as tabelas de um sistema costuma gerar um modelo que funciona nos testes e envelhece mal:

• Nenhuma restrição além da chave primária: sem UNIQUE, sem CHECK, às vezes sem chave estrangeira.
• Unicidade conferida só na aplicação.
• float ou double para dinheiro, timestamp sem fuso para datas.
• Chaves estrangeiras sem índice.
• Dados copiados entre tabelas sem uma fonte da verdade, ou o oposto: o preço do item lido do produto, mudando pedidos antigos.
• Listas guardadas como texto separado por vírgulas, ou um jsonb no lugar de tabelas.

O próximo nível compara as decisões de modelagem uma a uma: chaves, exclusão, histórico, tipos e quando desnormalizar.