Você já deve ter lido diversos artigos explicando o que é modelagem de dados. Mas, quando chega a hora de realmente criar um modelo para seu projeto, as dúvidas aparecem: por onde começar? Como traduzir as necessidades do negócio em um diagrama funcional? Como fazer um banco de dados no SQL?

Este artigo foi criado para ser seu guia prático, levando você desde a primeira conversa com o cliente até a implementação final do banco de dados.

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

O que é modelagem de dados?

Modelagem de dados é o processo de criar uma representação visual e estruturada de como as informações serão organizadas, armazenadas e relacionadas dentro de um sistema de banco de dados. Ou seja, trata-se de desenhar um mapa completo que mostra quais dados sua empresa precisa coletar, como esses dados se conectam entre si e de que forma eles serão acessados e utilizados no dia a dia.

Tipos de modelagem de dados

Antes de mergulharmos nas etapas práticas da modelagem, é importante entender que existem diferentes tipos de modelagem, cada um adequado para finalidades específicas.

Modelagem relacional

A modelagem relacional é o tipo mais comum e adequado para sistemas transacionais, aqueles usados no dia a dia das operações de uma empresa. Pense em um sistema de e-commerce onde clientes fazem pedidos, produtos são atualizados e pagamentos são processados. Todas essas são transações que precisam ser registradas e atualizadas constantemente.

Na modelagem relacional, as informações são organizadas em tabelas que se relacionam entre si por meio de chaves. A grande vantagem desse modelo é que ele minimiza redundância por meio de um processo chamado normalização. Cada informação tem seu lugar específico no banco de dados, e quando você precisa dela, busca por meio dos relacionamentos estabelecidos.

Por exemplo, em um sistema de gestão de clientes, você tem uma tabela de clientes com todas as informações pessoais, uma tabela de pedidos com os detalhes de cada compra e uma tabela de produtos com as informações dos itens vendidos. Quando você quer saber quais produtos um cliente específico comprou, o banco de dados segue os relacionamentos entre essas tabelas para trazer a informação completa.

A maioria dos sistemas de gerenciamento de banco de dados relacionais, como PostgreSQL, MySQL e SQL Server, é otimizada para esse tipo de modelagem.

Modelagem dimensional

Já a modelagem dimensional funciona de forma diferente e é especialmente indicada para sistemas de análise de dados, business intelligence e data warehouses. Enquanto a modelagem relacional prioriza evitar redundância, a modelagem dimensional prioriza facilitar consultas analíticas rápidas, mesmo que isso signifique repetir algumas informações.

Na modelagem dimensional, você organiza os dados ao redor de uma tabela fato central que contém as métricas numéricas que você quer analisar, como valores de vendas, quantidades e custos. Ao redor dessa tabela fato ficam as tabelas dimensão, que contêm os atributos descritivos que você usa para filtrar e agrupar suas análises, como informações de produtos, clientes, tempo e localização.

Voltando ao exemplo do e-commerce, uma tabela fato de vendas poderia conter o valor de cada venda, a quantidade vendida e o desconto aplicado. As dimensões descreveriam o contexto dessa venda: qual produto foi vendido, quem comprou, quando foi vendido e onde foi entregue.

Na prática, muitas empresas mantêm dois bancos de dados separados: um relacional para as operações do dia a dia e um data warehouse para análises estratégicas.

As etapas da modelagem de dados na prática

Agora que você compreende os conceitos fundamentais, vamos ao processo prático de criar um modelo de dados do zero.

A modelagem segue uma sequência lógica de etapas que se constroem umas sobre as outras, cada fase refinando e adicionando detalhes ao trabalho da fase anterior.

1. Entendimento do problema e coleta de requisitos

Antes de criar tabelas, diagramas ou escolher tecnologias, você precisa entender:

• O que o negócio precisa?

• Quais perguntas precisam ser respondidas?

• Quais processos precisam ser apoiados?

Como fazer isso na prática

• Reuniões de levantamento de requisitos.

• Entrevistas com usuários.

• Análise de processos já existentes.

• Mapear fluxos reais de informação.

Exemplo

Imagine que o negócio quer acompanhar vendas. As perguntas poderiam ser:

• Quanto vendemos por mês?

• Qual produto vende mais?

• Quem são os melhores clientes?

2. Identificação das entidades

Entidades são coisas importantes sobre as quais você quer guardar dados.

Normalmente são substantivos:

• Cliente.

• Produto.

• Pedido.

• Pagamento.

Como identificar entidades facilmente

Pegue uma frase do negócio:

O cliente compra produtos por meio de pedidos.

As entidades são:
Cliente;
Produto;
Pedido.

3. Definição dos atributos

Atributos são as informações que você guarda sobre cada entidade.

Exemplo

Entidade Cliente → atributos possíveis:

• id_cliente;

• nome;

• email;

• data_nascimento;

• cidade.

Entidade Produto:

• id_produto;

• nome;

• categoria;

• preço.

Dicas práticas

• Evite atributos duplicados.

• Cada atributo deve ter apenas um significado.

• Sempre inclua um identificador único, ou chave primária.

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

CONTINUA DEPOIS DO ANúNCIO

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

4. Definição dos relacionamentos

Relacionamento indica como as entidades se conectam.

Os tipos possíveis:

• 1 para 1 (1:1).

• 1 para muitos (1:N).

• Muitos para muitos (N:N).

Exemplos claros

• 1 cliente pode fazer muitos pedidos → Cliente 1:N Pedido.

• 1 pedido pode ter muitos produtos → Pedido N:N Produto.

Para resolver N:N, você cria uma tabela intermediária como Itens_do_Pedido.

Como saber o relacionamento?

Pergunte: um X pode ter quantos Y?

5. Normalização ou desnormalização

Normalização

É organizar as tabelas para:

• reduzir duplicidades;

• melhorar consistência;

• evitar problemas de atualização.

Usada principalmente em sistemas transacionais (OLTP).

Desnormalização

É simplificar tabelas para:

• melhorar performance de leitura;

• facilitar análises.

Usada em Data Warehouses, OLAP e BI.

Regra simples para iniciantes

• Se for sistema operacional → normalize.

• Se for para análise (BI e Analytics) → desnormalize em um modelo dimensional.

6. Criação do modelo conceitual (Diagrama ER)

É o modelo mais simples e visual, onde você mostra:

• Entidades.

• Relacionamentos.

Exemplo de como ficaria

Cliente ----(1:N)---- Pedido ----(N:N)---- Produto

Cliente ----(1:N)---- Pedido ----(N:N)---- Produto

Cliente ----(1:N)---- Pedido ----(N:N)---- Produto

7. Criação do modelo lógico

Aqui você já inclui detalhes técnicos, como:

• atributos;

• chaves primárias;

• chaves estrangeiras;

• cardinalidades exatas.

Exemplo

Tabela cliente

• id_cliente (PK).

• nome.

• email.

Tabela pedido

• id_pedido (PK).

• id_cliente (FK).

• data_pedido.

Mesmo neste nível, ainda não falamos de SQL nem do banco.

8. Criação do modelo físico

Agora, sim, definimos:

• tipo de dados (varchar, int, date);

• índices;

• constraints;

• nome exato das tabelas.

Exemplo real

CREATE TABLE cliente (
	id_cliente INT PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	email VARCHAR(150)
);

CREATE TABLE pedido (
	id_pedido INT PRIMARY KEY,
	id_cliente INT,
	data_pedido DATE,
	FOREIGN KEY (id_cliente) REFERENCES cliente(id_cliente)
)

CREATE TABLE cliente (
	id_cliente INT PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	email VARCHAR(150)
);

CREATE TABLE pedido (
	id_pedido INT PRIMARY KEY,
	id_cliente INT,
	data_pedido DATE,
	FOREIGN KEY (id_cliente) REFERENCES cliente(id_cliente)
)

CREATE TABLE cliente (
	id_cliente INT PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	email VARCHAR(150)
);

CREATE TABLE pedido (
	id_pedido INT PRIMARY KEY,
	id_cliente INT,
	data_pedido DATE,
	FOREIGN KEY (id_cliente) REFERENCES cliente(id_cliente)
)

9. Validação com o negócio e ajustes

Essa fase é fundamental.

Você apresenta o modelo e confirma:

• As entidades fazem sentido?

• Os atributos atendem às necessidades?

• Os relacionamentos estão corretos?

• Alguma informação está faltando?

É normal ajustar várias vezes. Modelagem é um processo iterativo.

Modelagem de dados: do zero até banco de dados

Agora vamos transformar tudo em prática real, como se você estivesse entrando no seu primeiro projeto de dados em uma empresa.

O cenário será simples, mas suficiente para entender 90% dos casos reais de modelagem de dados.

No nosso caso usaremos:

• Clientes;

• Produtos;

• Pedidos;

• Itens_do_pedido, que resolve o relacionamento N:N entre pedidos e produtos;

• Um cliente faz vários pedidos;

• Um pedido tem vários itens;

• Um item pertence a um produto;

• Um pedido pode ser fechado por um vendedor;

• Fato = evento (pedido, item do pedido);

• Dimensões = contexto (cliente, produto, vendedor).

Agora vamos para o SQL completo (modelo físico)

A partir daqui, você verá como isso vira um banco de dados real.

1. Criando a tabela cliente

-- Tabela de clientes
CREATE TABLE clientes (
	id_cliente SERIAL PRIMARY KEY,
	nome VARCHAR(100) NOT NULL,
	email VARCHAR(100) NOT NULL UNIQUE,
	cpf VARCHAR(11) UNIQUE,
	telefone VARCHAR(15),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Índice para facilitar buscas por email
CREATE INDEX idx_clientes_email ON clientes(email)

-- Tabela de clientes
CREATE TABLE clientes (
	id_cliente SERIAL PRIMARY KEY,
	nome VARCHAR(100) NOT NULL,
	email VARCHAR(100) NOT NULL UNIQUE,
	cpf VARCHAR(11) UNIQUE,
	telefone VARCHAR(15),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Índice para facilitar buscas por email
CREATE INDEX idx_clientes_email ON clientes(email)

-- Tabela de clientes
CREATE TABLE clientes (
	id_cliente SERIAL PRIMARY KEY,
	nome VARCHAR(100) NOT NULL,
	email VARCHAR(100) NOT NULL UNIQUE,
	cpf VARCHAR(11) UNIQUE,
	telefone VARCHAR(15),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Índice para facilitar buscas por email
CREATE INDEX idx_clientes_email ON clientes(email)

Por que assim?
E-mail deve ser único;
Data de cadastro é obrigatória;
Nome pode mudar, mas ID nunca.

Para não ter dúvidas: os produtos são independentes e podem ser criados antes dos pedidos, sem nenhum problema.

2. Tabela produto

CREATE TABLE produtos (
	id_produto SERIAL PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	categoria VARCHAR(100),
	preco DECIMAL(10,2) NOT NULL CHECK (preco >= 0),
	estoque INT DEFAULT 0 CHECK (estoque >= 0),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)

CREATE TABLE produtos (
	id_produto SERIAL PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	categoria VARCHAR(100),
	preco DECIMAL(10,2) NOT NULL CHECK (preco >= 0),
	estoque INT DEFAULT 0 CHECK (estoque >= 0),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)

CREATE TABLE produtos (
	id_produto SERIAL PRIMARY KEY,
	nome VARCHAR(150) NOT NULL,
	categoria VARCHAR(100),
	preco DECIMAL(10,2) NOT NULL CHECK (preco >= 0),
	estoque INT DEFAULT 0 CHECK (estoque >= 0),
	data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)

Por que assim?
Preço precisa de decimal;
Categoria é opcional;
Nome sempre obrigatório.

Agora podemos criar pedidos, que dependem de clientes. Cada pedido está ligado a 1 cliente, em uma relação 1:N.

3. Tabela vendedor

Por que assim?
Nem todo vendedor tem departamento definido.
ID com autoincremento é padrão.

Agora falta conectar pedidos ao que realmente foi comprado, então usamos a tabela itens_do_pedido.

4. Tabela pedido

CREATE TABLE pedidos (
	id_pedido INT PRIMARY KEY AUTO_INCREMENT,
	id_cliente INT NOT NULL,
	id_vendedor INT,
	data_pedido DATE NOT NULL,
	FOREIGN KEY (id_cliente) REFERENCES clientes(id_cliente),
	FOREIGN KEY (id_vendedor) REFERENCES vendedores(id_vendedor)
)

CREATE TABLE pedidos (
	id_pedido INT PRIMARY KEY AUTO_INCREMENT,
	id_cliente INT NOT NULL,
	id_vendedor INT,
	data_pedido DATE NOT NULL,
	FOREIGN KEY (id_cliente) REFERENCES clientes(id_cliente),
	FOREIGN KEY (id_vendedor) REFERENCES vendedores(id_vendedor)
)

CREATE TABLE pedidos (
	id_pedido INT PRIMARY KEY AUTO_INCREMENT,
	id_cliente INT NOT NULL,
	id_vendedor INT,
	data_pedido DATE NOT NULL,
	FOREIGN KEY (id_cliente) REFERENCES clientes(id_cliente),
	FOREIGN KEY (id_vendedor) REFERENCES vendedores(id_vendedor)
)

Conexão com o negócio:
Todo pedido tem um cliente.
Nem sempre tem vendedor, como em pedidos automáticos.

5. Tabela itens do pedido

Essa tabela resolve o relacionamento N:N:

• 1 pedido pode ter vários produtos.

• 1 produto pode estar em vários pedidos.

CREATE TABLE itens_pedido (
	id_item INT PRIMARY KEY AUTO_INCREMENT,
	id_pedido INT NOT NULL,
	id_produto INT NOT NULL,
	quantidade INT NOT NULL,
	preco_unitario DECIMAL(10,2) NOT NULL,
	FOREIGN KEY (id_pedido) REFERENCES pedidos(id_pedido),
	FOREIGN KEY (id_produto) REFERENCES produtos(id_produto)
)

CREATE TABLE itens_pedido (
	id_item INT PRIMARY KEY AUTO_INCREMENT,
	id_pedido INT NOT NULL,
	id_produto INT NOT NULL,
	quantidade INT NOT NULL,
	preco_unitario DECIMAL(10,2) NOT NULL,
	FOREIGN KEY (id_pedido) REFERENCES pedidos(id_pedido),
	FOREIGN KEY (id_produto) REFERENCES produtos(id_produto)
)

CREATE TABLE itens_pedido (
	id_item INT PRIMARY KEY AUTO_INCREMENT,
	id_pedido INT NOT NULL,
	id_produto INT NOT NULL,
	quantidade INT NOT NULL,
	preco_unitario DECIMAL(10,2) NOT NULL,
	FOREIGN KEY (id_pedido) REFERENCES pedidos(id_pedido),
	FOREIGN KEY (id_produto) REFERENCES produtos(id_produto)
)

Por que assim?
O preço unitário é salvo no momento da compra, então se o preço do produto mudar, o histórico não se perde.
A quantidade nunca pode ser 0.

Transforme dados em decisões estratégicas

O conhecimento que você adquiriu aqui é fundamental, mas representa apenas o começo da jornada de um analista de dados completo. Dominar SQL e modelagem é essencial, porém o mercado procura profissionais que também saibam formular hipóteses de negócio, extrair insights relevantes e comunicar descobertas de forma convincente para stakeholders.

O Curso Data Analytics da Tera oferece a formação completa que você precisa. São mais de 36 horas de conteúdo prático abordando SQL avançado, métricas de negócio, storytelling com dados e análise estratégica.

Você aprende com especialistas de empresas como Itaú, Mercado Livre e iFood, desenvolvendo projetos reais para seu portfólio e fortalecendo sua atuação em dados e negócios.

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga

membership

TUDO LIBERADO: Assine 1 vez, tenha acesso para sempre.

Domine ferramentas como Lovable, Claude, n8n, Gemini e ChatGPT para multiplicar sua produtividade e tirar qualquer ideia do papel.

Garantir minha vaga