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.

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.

Resumo

A modelagem de dados move um domínio através de três camadas de compromisso crescente: conceitual (o que existe), lógica (como se relaciona) e física (como o PostgreSQL armazena).
Por que Importa: Esquemas projetados com foco no físico tendem a codificar detalhes de implementação acidentais como se fossem regras de negócios, tornando as mudanças futuras caras.
Conceitos-Chave: modelo conceitual, modelo lógico, modelo físico, entidade, atributo, evolução de esquema.
Quando Usar: Qualquer design de esquema novo (greenfield), qualquer revisão da intenção de um esquema existente e qualquer discussão sobre se a forma de uma tabela reflete o domínio ou apenas os atalhos de uma migração passada.
Limitações / Trade-offs: Um processo estrito de três camadas adiciona tempo de design inicial que um pequeno protótipo pode não precisar.
Tópicos Relacionados: modelagem entidade-relacionamento, normalização, evolução de esquema, limites de esquema orientados a domínio.

Fundamentos

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.

Mecânicas e Interações

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.

Considerações Avançadas e Aplicações

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.

Equívocos Comuns

"O ERD é documentação, o esquema é o design real." O ERD (ou seu equivalente esboço conceitual) é o design; o esquema é uma possível renderização física dele, e tratar o diagrama como um pensamento posterior é como os esquemas se desviam do domínio que afirmam representar.
"Normalização e modelagem física são o mesmo passo." 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.
"Um bom esquema nunca muda." Todo esquema para um produto vivo muda, e o objetivo da disciplina de modelagem é tornar essa mudança barata e segura, não impedi-la de acontecer.
"Chaves substitutas são sempre a escolha certa." Chaves substitutas são o padrão sensato para tabelas OLTP, mas um negócio já tem uma chave natural globalmente única (um código de moeda ISO, por exemplo) que essa chave natural pode ser a chave primária sem danos.
"Modelagem é uma fase inicial única." Modelagem é uma atividade recorrente que acontece toda vez que uma nova entidade, relacionamento ou regra de negócios aparece, não uma fase que termina quando a primeira migração é enviada.

FAQs

Qual é a diferença entre um modelo de dados conceitual, lógico e físico?

Um modelo conceitual nomeia entidades e relacionamentos em linguagem de negócios, sem envolvimento de tecnologia de banco de dados.
Um modelo lógico adiciona atributos, cardinalidade e identidade, enquanto permanece tecnologicamente neutro em princípio.
Um modelo físico é a renderização do PostgreSQL: tabelas, colunas tipadas, chaves estrangeiras, índices e restrições.

Preciso produzir três documentos separados para cada alteração de esquema?

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.

Por que começar com DDL causa problemas depois?

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.

Como os esquemas do PostgreSQL se relacionam com a modelagem conceitual?

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 faz parte da modelagem de dados ou é um tópico separado?

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.

Como sei quando uma regra de negócios deve se tornar uma restrição de banco 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.

O que é evolução de esquema e como ela se relaciona com a modelagem?

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 um contexto delimitado deve ter seu próprio banco de dados em vez de seu próprio esquema?

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 sempre melhores que chaves naturais?

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 que significa um esquema "desviar" de seu modelo?

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.

Por que as convenções de nomenclatura importam tanto para a modelagem?

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.

Como esta página se relaciona com as outras páginas desta seção?

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.

Relacionados

Noções Básicas de Modelagem de Dados - exemplos práticos do fluxo conceitual para físico
Modelagem Entidade-Relacionamento - cardinalidade, opcionalidade e nomenclatura
Estratégia de Evolução de Esquema - migrações expandir-contrair ao longo do tempo
Limites de Esquema Orientados a Domínio - agrupamento de entidades por contexto delimitado
ADR: Banco de Dados Único vs. Banco de Dados por Serviço - a decisão de limite de banco de dados
Noções Básicas de Normalização - a disciplina da camada lógica por trás do posicionamento de atributos

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17).