Fundamentos de Modelagem de Dados
Modelagem de dados é a disciplina de decidir o que um banco de dados deve representar antes de decidir como o PostgreSQL deve armazená-lo.
//
Busque em todas as páginas da documentação
Modelagem de dados é a disciplina de decidir o que um banco de dados deve representar antes de decidir como o PostgreSQL deve armazená-lo.
Cada tabela, chave estrangeira e restrição em um esquema de produção é uma resposta física a uma pergunta que foi feita primeiro em termos de negócios, como "o que é um pedido" ou "um cliente pode existir sem uma conta".
Esta página apresenta o modelo mental no qual o restante desta seção se baseia: as três camadas de modelagem, como elas se comunicam entre si e onde as mecânicas específicas do PostgreSQL entram em cena.
Um modelo conceitual nomeia as coisas que um negócio valoriza, independentemente de qualquer tecnologia de banco de dados.
Ele identifica entidades como Cliente, Pedido e Produto, e os relacionamentos entre elas, usando o vocabulário que o próprio negócio utiliza.
Um modelo lógico pega esse esboço conceitual e adiciona estrutura: atributos são atribuídos a entidades, relacionamentos recebem cardinalidade (um-para-muitos, muitos-para-muitos) e a identidade é definida.
O modelo lógico ainda é tecnologicamente agnóstico em princípio, embora na prática a maioria das equipes pense em termos relacionais quando chega a esse estágio.
Um modelo físico é onde o PostgreSQL entra: entidades se tornam instruções CREATE TABLE, atributos se tornam colunas tipadas e relacionamentos se tornam chaves estrangeiras, índices e restrições.
É também onde residem as decisões específicas do PostgreSQL, como a escolha de bigint GENERATED ALWAYS AS IDENTITY para chaves substitutas ou timestamptz em vez de timestamp without time zone.
As três camadas não são três documentos separados que a maioria das equipes mantém para sempre; são três perguntas separadas que são feitas, aproximadamente em ordem, toda vez que um esquema muda.
Pular direto para a camada física é o modo de falha mais comum, porque parece produtivo escrever DDL imediatamente.
O custo aparece mais tarde, quando uma coluna adicionada sob pressão de prazo acaba codificando uma suposição com a qual ninguém realmente concordou.
A passagem de bastão entre as camadas é onde a maioria dos defeitos de modelagem são realmente introduzidos, não dentro de qualquer camada única.
Uma entidade conceitual como "Pedido" pode ser mapeada para uma tabela, ou pode ser mapeada para várias tabelas se o modelo lógico decidir que um pedido tem um ciclo de vida distinto de seus itens de linha.
Essa decisão, uma tabela versus várias, é uma escolha da camada lógica, e deve ser feita perguntando o que muda independentemente, não perguntando o que é conveniente para JOIN.
O namespace de esquema do PostgreSQL (CREATE SCHEMA) fornece à camada física uma ferramenta para expressar limites conceituais sem o custo de bancos de dados separados.
-- Limite conceitual expresso fisicamente como um esquema, não um novo banco de dados
CREATE SCHEMA billing;
CREATE SCHEMA catalog;
CREATE TABLE billing.invoices (
invoice_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
amount numeric(12, 2) NOT NULL
);Isso permite que um único banco de dados físico ainda comunique "estas tabelas pertencem a diferentes partes do domínio" através de nomes e permissões, em vez de apenas pela memória do desenvolvedor.
Restrições são o outro lugar onde as camadas interagem diretamente umas com as outras.
Uma restrição CHECK ou uma coluna NOT NULL é um mecanismo físico que impõe uma regra declarada na camada conceitual, como "um pedido não pode ser marcado como enviado sem uma data de envio".
Quando uma restrição no esquema não se mapeia de volta a uma regra de negócios declarada, isso geralmente é um sinal de que a camada física se afastou do modelo que deveria representar.
Inversamente, uma regra de negócios que existe apenas no código da aplicação e não em qualquer restrição é uma regra que o banco de dados não pode proteger, e uma migração futura ou uma consulta ad-hoc podem violá-la silenciosamente.
Decisões de modelagem raramente são tomadas uma vez e depois deixadas de lado, porque o próprio domínio muda à medida que um produto cresce.
Evolução de esquema é a prática de mover um modelo físico para frente sem quebrar o contrato lógico do qual outros serviços e códigos dependem.
O padrão que a maioria das equipes adota é expandir-contrair: adicionar novas colunas ou tabelas ao lado das antigas, migrar leitores e escritores gradualmente, e então remover a forma antiga quando nada mais depender dela.
Em maior escala, as equipes também precisam decidir onde um limite de domínio se torna um limite de banco de dados, não apenas um limite de esquema.
Limites de esquema orientados a domínio aplicam o mesmo pensamento de entidade conceitual a uma pergunta mais difícil: esse contexto delimitado deve ter seu próprio esquema ou seu próprio banco de dados inteiro.
Essa decisão troca consistência e conveniência de JOIN (banco de dados único) contra isolamento de raio de explosão e capacidade de implantação independente (bancos de dados separados), e merece seu próprio registro explícito em vez de um acúmulo implícito de tabelas.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Modelagem Conceitual-Primeiro | Esquema reflete regras de negócios reais, não histórico de migração | Mais lento para começar; requer conversas de domínio antecipadamente | Novos domínios, ou domínios com propriedade incerta |
| Físico-Primeiro (DDL imediatamente) | Rápido para prototipar | Esquema codifica decisões acidentais como se fossem regras | Apenas protótipos verdadeiramente descartáveis |
| Banco de dados único, múltiplos esquemas | Transação única, junções fáceis entre entidades | Implantações acopladas e raio de explosão entre contextos delimitados | Domínios relacionados com consultas frequentes entre entidades |
| Banco de dados por contexto delimitado | Isolamento forte, escalonamento e implantações independentes | Consultas entre contextos exigem APIs ou replicação, não junções | Domínios com diferentes necessidades de propriedade, conformidade ou escalonamento |
Convenções de nomenclatura merecem a mesma deliberadeza que a forma das tabelas, pois são a interface que todo engenheiro futuro lê antes de ler qualquer código.
Uma regra consistente para chaves primárias, chaves estrangeiras e tabelas de junção transforma caminhos de JOIN em algo que um leitor pode prever em vez de algo que ele precisa procurar toda vez.
Não, as três camadas são três perguntas a serem trabalhadas, não três entregáveis para manter para sempre.
Para uma mudança pequena e bem compreendida, as perguntas conceituais e lógicas podem ser respondidas em uma breve conversa antes que o DDL seja escrito.
Escrever CREATE TABLE primeiro tende a codificar o que quer que fosse conveniente naquele momento como se fosse uma regra de negócios.
Leitores posteriores não conseguem dizer quais colunas representam decisões deliberadas e quais são acidentes de uma migração apressada.
Um namespace CREATE SCHEMA do PostgreSQL é uma ferramenta de camada física para expressar um limite conceitual, como faturamento versus catálogo, sem o custo de bancos de dados separados.
É uma maneira leve de tornar os contextos delimitados visíveis no modelo físico.
A normalização é uma disciplina de camada lógica sobre eliminar redundância e anomalias de atualização; modelagem física é sobre como o PostgreSQL armazena o resultado normalizado, e as duas perguntas podem ter respostas diferentes.
Ela é abordada em sua própria página porque tem profundidade suficiente para merecer uma, mas não é uma disciplina separada da modelagem de dados.
Se violar a regra produzisse dados objetivamente errados, não apenas incomuns, ela pertence a uma restrição.
Se a regra é uma preferência suave que legitimamente muda por contexto, geralmente pertence à lógica da aplicação.
Evolução de esquema é a prática de alterar um modelo físico ao longo do tempo sem quebrar o contrato lógico do qual outro código depende.
É o lado contínuo e iterativo do mesmo processo de modelagem descrito nesta página.
Quando o contexto tem propriedade diferente, requisitos de conformidade diferentes ou necessidades de escalonamento que entram em conflito com seus vizinhos, um banco de dados separado oferece isolamento mais forte do que um esquema pode oferecer.
Um esquema é suficiente quando os contextos estão relacionados e são consultados frequentemente juntos.
Chaves substitutas são o padrão mais seguro porque são estáveis e estreitas, mas uma chave natural genuinamente global e imutável pode servir como chave primária sem as anomalias que as chaves substitutas existem para evitar.
A decisão deve decorrer de se a chave natural pode mudar ou colidir, não de hábito.
O desvio acontece quando mudanças físicas (uma coluna adicionada sob pressão de prazo, uma restrição silenciosamente removida) se acumulam sem que ninguém atualize a compreensão conceitual ou lógica do domínio.
O sintoma é um esquema que ninguém mais consegue explicar completamente.
Nomenclatura consistente transforma cada caminho JOIN futuro em algo previsível em vez de algo que requer a consulta do esquema primeiro.
É uma maneira barata e duradoura de manter o modelo físico legível à medida que uma equipe cresce.
Esta página fornece o vocabulário e o processo que a modelagem entidade-relacionamento, a evolução de esquema e os limites orientados a domínio aprofundam.
Leia esta primeiro se a relação entre essas páginas não estiver clara.
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17).
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026