Modelo físico de banco de dados: do projeto ao SQL

O modelo físico de banco de dados especifica como o projeto será implementado em um sistema gerenciador de banco de dados, ou SGBD. Em um banco relacional, isso inclui tabelas, nomes de colunas, tipos, nulabilidade, chaves, restrições e estruturas de acesso. Dependendo do projeto, também abrange particionamento e decisões de armazenamento.

Um desenho com entidades e relacionamentos ajuda a entender o negócio, mas ainda não determina todas essas escolhas. Para implementar, você precisa decidir como cada conceito será representado no gerenciador selecionado. Os exemplos deste guia usam recursos do PostgreSQL e representam um cenário didático, sem pressupor uma aplicação em produção.

Do conceitual ao físico: onde entram as decisões

Essa divisão é uma ferramenta de raciocínio, não uma proibição de revisar etapas anteriores. Ao escolher um tipo ou uma restrição, você pode descobrir que uma regra estava ambígua. Volte ao significado antes de criar uma solução técnica que apenas esconda o problema. O guia de banco de dados relacionais desenvolve essa base.

Escolha tipos pelo significado e pelas operações

A documentação de criação de tabelas do PostgreSQL mostra que a declaração reúne colunas e tipos. Um identificador inteiro, uma data e um texto exigem representações diferentes. Usar texto em todos os campos transfere validações para consultas e aplicações, além de tornar comparações e ordenações mais difíceis de interpretar.

A escolha numérica também importa. A documentação de tipos numéricos diferencia representações exatas e aproximadas. Um valor monetário pode exigir decimal exato, enquanto uma medida física pode admitir ponto flutuante. A precisão adequada decorre do domínio, do intervalo esperado e das operações necessárias.

Pense ainda no que a ausência significa. Uma data de cancelamento pode ficar nula porque a inscrição continua ativa; uma identificação obrigatória não deveria faltar. Documentar essa semântica evita que NULL, zero e texto vazio sejam usados como se expressassem a mesma condição.

Exemplo de implementação física em SQL

No cenário hipotético, cada disciplina possui um código e uma carga horária positiva. Cada estudante possui um identificador, e cada inscrição relaciona um estudante a uma disciplina. A regra escolhida para o exercício permite apenas uma inscrição por par de identificadores. Essa regra seria diferente em um sistema que registra ofertas semestrais.

O identificador distingue a linha. O código também precisa ser único, mas possui outro significado no domínio. A carga horária combina tipo inteiro, obrigatoriedade e verificação positiva. Declarar apenas CHECK não substitui NOT NULL: uma expressão de verificação pode admitir resultado desconhecido quando recebe valor nulo.

As restrições do PostgreSQL permitem expressar essas condições de integridade. As chaves estrangeiras exigem correspondência com registros referenciados; a chave composta impede repetir o mesmo par. Uma alteração na regra do negócio pode exigir revisar essa estrutura, não apenas aumentar o tamanho de um campo.

Gerar um identificador não equivale a garantir unicidade

Em vez de fornecer todos os números manualmente, você pode escolher uma coluna de identidade, como id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY. A documentação de identity columns distingue a geração automática da restrição de unicidade. A chave primária continua sendo uma decisão explícita de integridade.

No modelo físico, registre também o comportamento de exclusões e atualizações de referências. Apagar uma disciplina deve impedir a operação quando há inscrições, apagar inscrições associadas ou preservar um histórico por outra estratégia? Nenhuma dessas respostas é universal. A política precisa corresponder ao ciclo de vida dos dados.

Índices devem responder às consultas esperadas

A introdução a índices do PostgreSQL explica seu papel no acesso aos dados. Um índice pode reduzir o trabalho de localizar linhas, mas ocupa espaço e precisa ser mantido quando os dados mudam. Criar índices indiscriminadamente não é uma estratégia de desempenho.

No exemplo, a chave composta começa por estudante_id. Se uma consulta frequente busca inscrições por disciplina_id, vale avaliar um índice nessa coluna: CREATE INDEX inscricao_disciplina_idx ON inscricao (disciplina_id);. A pertinência depende do volume, da distribuição dos valores e das consultas reais. A chave estrangeira não cria automaticamente esse índice na tabela que referencia.

O comando EXPLAIN permite examinar o plano escolhido pelo PostgreSQL. Compare cenários com dados representativos e estatísticas adequadas. Uma tabela minúscula pode ser lida sequencialmente mesmo quando existe índice; isso não demonstra, por si só, um defeito no projeto.

Como revisar o modelo antes de implementar

Crie dados pequenos que deveriam ser aceitos e outros que deveriam ser rejeitados: código repetido, carga horária negativa, inscrição sem estudante e par duplicado. Confira se as falhas correspondem às regras documentadas. Depois experimente as consultas que a aplicação precisa responder, definindo o significado de cada linha do resultado.

Mantenha alterações de esquema em migrações versionadas e registre suas razões. Para continuar o estudo, relacione a modelagem às estruturas de dados: organização e acesso influenciam custos, mas a implementação precisa primeiro preservar o significado. Um bom modelo físico torna as decisões verificáveis e suas limitações explícitas.