Diagramas Entidade-Relacionamento: Um Guia Prático de Design de Banco de Dados

Um schema de banco de dados escrito sem um diagrama é um palpite. Você pode acertar as tabelas na primeira tentativa, mas quase certamente irá perder um relacionamento, colocar uma chave estrangeira no lugar errado ou construir uma estrutura que resiste às consultas que sua aplicação realmente precisa. Diagramas entidade-relacionamento — diagramas ER — são a ferramenta padrão para projetar e comunicar a estrutura do banco de dados antes de escrever uma única linha de SQL.

Diagramas ER são úteis não apenas no design inicial, mas ao longo do ciclo de vida de um sistema: integrar engenheiros que precisam entender um schema existente, planejar migrações, identificar problemas de normalização e documentar o modelo de dados para stakeholders não técnicos.

O que é um diagrama ER?

Um diagrama ER (diagrama entidade-relacionamento) é uma representação visual das entidades em um banco de dados e dos relacionamentos entre elas. Mostra quais dados o sistema armazena, quais atributos cada entidade possui e como as entidades se relacionam entre si.

O conceito foi introduzido por Peter Chen em 1976 e tem sido estendido e adaptado por ferramentas e profissionais de banco de dados desde então. Dois estilos de notação dominam a prática moderna: notação Chen (design conceitual) e notação Pé de Galinha (focada em implementação, usada pela maioria das ferramentas modernas).

Diagramas ER operam em diferentes níveis de abstração:

Nível	Propósito	Público
Conceitual	Entidades e relacionamentos em alto nível	Stakeholders de negócio, PMs
Lógico	Atributos, chaves, cardinalidade adicionados	Arquitetos de banco de dados
Físico	Tipos de dados, índices, chaves estrangeiras, pronto para SQL	Desenvolvedores, DBAs

Conceitos principais

Entidades

Uma entidade é algo sobre o qual o banco de dados armazena informações. Mapeia para uma tabela no banco de dados implementado.

Entidade forte: Existe independentemente. Tem sua própria chave primária. Exemplo: Cliente, Produto, Pedido
Entidade fraca: Depende de outra entidade para sua existência. Exemplo: ItemPedido depende de Pedido

Convenções de nomenclatura de entidades:

Use substantivos no singular (Pedido, não Pedidos)
PascalCase é comum para nomes de entidades
Nomeie o que a linha representa, não a coleção

Atributos

Atributos são propriedades de uma entidade. Mapeiam para colunas na tabela implementada.

Tipo de Atributo	Descrição	Exemplo
Simples	Valor único e atômico	`primeiroNome`, `preco`
Composto	Composto de subatributos	`endereco` = rua + cidade + cep
Derivado	Calculado de outros atributos	`idade` derivada de `dataNascimento`
Multivalorado	Pode ter múltiplos valores	`telefones` (uma pessoa pode ter vários)
Atributo chave	Identifica unicamente uma instância	`clienteId`, `email`

Em diagramas ER físicos, especifique tipos de dados ao lado dos nomes de atributos:

Cliente
├── clienteId  INT PRIMARY KEY
├── email       VARCHAR(255) UNIQUE NOT NULL
├── primeiroNome VARCHAR(100) NOT NULL
├── ultimoNome  VARCHAR(100) NOT NULL
├── criadoEm   TIMESTAMP DEFAULT NOW()
└── status      ENUM('ativo', 'inativo', 'banido')

Relacionamentos

Um relacionamento define como duas entidades estão associadas. Mapeia para uma restrição de chave estrangeira (ou uma tabela de junção para relacionamentos muitos-para-muitos) no schema implementado.

Relacionamentos têm:

Nome: descreve a associação (coloca, contém, pertence a)
Cardinalidade: quantas instâncias de cada entidade podem participar
Participação: se a participação é obrigatória (total) ou opcional (parcial)

Cardinalidade

Cardinalidade é o conceito mais importante na modelagem ER. Define o relacionamento numérico entre instâncias de entidades.

Cardinalidade	Significado	Exemplo
Um-para-Um	Uma instância A se relaciona com exatamente uma instância B	`Usuário` tem um `Perfil`
Um-para-Muitos	Uma instância A se relaciona com muitas instâncias B	`Cliente` coloca muitos `Pedidos`
Muitos-para-Um	Muitas instâncias A se relacionam com uma instância B	Muitos `Pedidos` pertencem a um `Cliente`
Muitos-para-Muitos	Muitas instâncias A se relacionam com muitas instâncias B	`Estudantes` se matriculam em muitos `Cursos`

Relacionamentos muitos-para-muitos não podem ser implementados diretamente em um banco de dados relacional. Eles requerem uma tabela de junção (também chamada de tabela de associação ou entidade associativa):

Estudante ──< Matricula >── Curso

A tabela Matricula contém as chaves estrangeiras para Estudante e Curso, além de qualquer atributo da matrícula em si (como dataMatricula ou nota).

Estilos de notação

Notação Chen

A notação Chen é a notação acadêmica original. Usa formas geométricas:

Retângulo: Entidade
Elipse: Atributo
Losango: Relacionamento
Linha: Conexão
Elipse dupla: Atributo multivalorado
Elipse tracejada: Atributo derivado
Retângulo duplo: Entidade fraca
Losango duplo: Relacionamento identificador (para entidades fracas)

Exemplo ASCII de notação Chen:

 (clienteId)   (email)    (primeiroNome)
      |             |           |
      └─────────────┴───────────┘
                    |
              ┌─────────┐
              │ Cliente │
              └────┬────┘
                   │
              <  coloca  >
                   │
              ┌─────────┐
              │  Pedido │
              └─────────┘

A notação Chen é útil para modelagem conceitual porque torna relacionamentos e atributos explícitos. Fica desorganizada para schemas grandes.

Notação Pé de Galinha

A notação Pé de Galinha é o estilo dominante nas ferramentas modernas de banco de dados (MySQL Workbench, dbdiagram.io, ERDPlus). Ela codifica a cardinalidade diretamente na linha de relacionamento usando símbolos em cada extremidade.

Símbolos Pé de Galinha:

Símbolo na extremidade da linha   Significado
─────────────────────────────    ──────────────────────────────
      ──|            Exatamente um (obrigatório)
      ──o            Zero ou um (opcional)
      ──<            Muitos (um ou mais)
      ──o<           Zero ou mais (muitos opcionais)
      ──|<           Um ou mais (muitos obrigatórios)
      ──||           Exatamente um (em ambos os lados)

Exemplo Pé de Galinha — relacionamentos de e-commerce:

Cliente ||──o< Pedido ||──|< ItemPedido >|──|| Produto

Lendo isso: um Cliente tem zero ou mais Pedidos; cada Pedido tem um ou mais ItensPedido; cada ItemPedido referencia exatamente um Produto.

Entidade completa com Pé de Galinha:

┌─────────────┐       ┌─────────────┐       ┌──────────────────┐
│   Cliente   │       │   Pedido    │       │    ItemPedido    │
│─────────────│       │─────────────│       │──────────────────│
│ PK id       │||──o<─│ PK id       │||──|<─│ PK id            │
│    email    │       │ FK clienteId│       │ FK pedidoId      │
│    nome     │       │    status   │       │ FK produtoId     │
│    criadoEm │       │    total    │       │    quantidade    │
└─────────────┘       │    criadoEm │       │    precoUnitario │
                      └─────────────┘       └──────────────────┘

Pé de Galinha é preferido para diagramas ER lógicos e físicos porque é mais compacto que a notação Chen e reflete diretamente a estrutura do schema SQL.

O diagrama ER no processo de design de banco de dados

Diagramas ER se encaixam no design de banco de dados em múltiplos estágios:

1. Levantamento de requisitos Trabalhe com stakeholders para identificar as coisas que o sistema precisa rastrear. Cada substantivo nos requisitos é uma entidade potencial. Cada fato sobre um substantivo é um atributo potencial.

2. Design conceitual Desenhe entidades e relacionamentos sem se preocupar com detalhes de implementação. Foque no que os dados significam, não em como são armazenados.

3. Design lógico Adicione atributos, defina chaves primárias, resolva relacionamentos muitos-para-muitos em tabelas de junção, especifique cardinalidade.

4. Design físico Adicione tipos de dados, índices, restrições e especificações NULL/NOT NULL. O diagrama ER neste estágio deve mapear diretamente para SQL DDL.

5. Revisão e refinamento Valide o schema contra consultas reais: você consegue recuperar os dados que sua aplicação precisa de forma eficiente? O schema suporta todas as operações necessárias?

Guia de criação passo a passo

Passo 1: Identificar entidades

Leia os requisitos ou histórias de usuário e destaque substantivos que representam conceitos distintos que o sistema rastreia. Comece pelos óbvios.

Para um sistema de e-commerce:

Cliente, Produto, Pedido, Categoria, Avaliação, Endereco, Pagamento

Regras práticas:

Se tem múltiplas instâncias, provavelmente é uma entidade (não um atributo)
Se tem seus próprios atributos, provavelmente é uma entidade
Se outras entidades se referem a ela independentemente, é uma entidade

Passo 2: Definir atributos para cada entidade

Para cada entidade, liste suas propriedades. Identifique:

A chave primária (identificador único, gerado pelo sistema ou natural)
Atributos obrigatórios (NOT NULL em SQL)
Atributos opcionais
Atributos que podem ser compostos (endereço) ou multivalorados (tags)

Evite armazenar dados derivados a menos que o desempenho exija. idade é derivável de dataNascimento; armazenar ambos cria problemas de consistência.

Passo 3: Mapear relacionamentos

Para cada par de entidades que interagem, defina o relacionamento:

Nomeie o relacionamento (frase verbal da perspectiva de uma entidade)
Determine a cardinalidade (um-para-um, um-para-muitos, muitos-para-muitos)
Determine a participação (cada lado é obrigatório ou opcional?)

Escreva como uma frase e verifique se faz sentido em ambas as direções:

"Um Cliente coloca zero ou mais Pedidos"
"Um Pedido é colocado por exatamente um Cliente"

Passo 4: Resolver relacionamentos muitos-para-muitos

Todo relacionamento muitos-para-muitos se torna uma tabela de junção. Identifique atributos do próprio relacionamento (se houver) — esses se tornam colunas na tabela de junção.

Estudante ──< Matricula >── Curso

Atributos da Matricula:
- dataMatricula
- nota
- status (ativo, desistiu, concluído)

Passo 5: Atribuir tipos de dados e restrições

Para cada atributo, especifique:

Tipo de dado (INT, VARCHAR(n), DECIMAL(10,2), TIMESTAMP, BOOLEAN)
NULL / NOT NULL
Valores padrão
Restrições únicas
Restrições de verificação (ex.: preco > 0)

Passo 6: Validar contra consultas

Escreva as consultas principais que sua aplicação irá executar e rastreie-as pelo schema. Se uma consulta requer múltiplas junções que poderiam ter sido evitadas com melhor design, revise o schema.

Verifique:

Você consegue recuperar o histórico completo de pedidos de um cliente?
Você consegue encontrar todos os produtos em uma categoria?
Você consegue calcular totais de pedidos a partir de itens?
Você consegue gerar relatórios de receita por intervalo de datas?

Considerações de normalização

Normalização é o processo de estruturar um schema para reduzir redundância de dados e melhorar a integridade. As três formas normais mais comumente aplicadas:

Primeira Forma Normal (1FN): Cada coluna contém valores atômicos. Sem grupos repetidos. Cada linha é unicamente identificável.

Segunda Forma Normal (2FN): Atende à 1FN. Todo atributo não-chave é totalmente dependente da chave primária inteira (relevante para chaves compostas).

Terceira Forma Normal (3FN): Atende à 2FN. Sem dependências transitivas — atributos não-chave dependem apenas da chave primária, não de outros atributos não-chave.

Exemplo de violação de 3FN: armazenar cidadeCliente na tabela Pedido. A cidade depende do cliente, não do pedido. Se o cliente se mudar, você deve atualizar cada registro de pedido.

Quando desnormalizar: A normalização otimiza para consistência de escrita. Cargas de trabalho analíticas de leitura intensiva às vezes se beneficiam de estruturas desnormalizadas (visões materializadas, tabelas de relatório) que evitam junções custosas. Tome isso como decisão deliberada, não por acidente.

Erros comuns

Usar chaves naturais como chaves primárias. Endereços de email mudam. Números de seguridade social não devem ser armazenados. Nomes não são únicos. Use chaves substitutas (inteiros com auto-incremento ou UUIDs) como chaves primárias e adicione restrições únicas a identificadores naturais.

Armazenar listas em uma única coluna. Uma coluna tags contendo valores separados por vírgula viola a 1FN. Use uma tabela de junção (TagProduto) em vez disso.

Falta de atributos na tabela de junção. Ao resolver um relacionamento muitos-para-muitos, equipes frequentemente criam uma tabela de junção simples com apenas duas chaves estrangeiras. Pense em atributos que pertencem ao próprio relacionamento — data de matrícula, quantidade do pedido, nível de permissão.

Confundir entidades com atributos. Endereco em um sistema simples pode ser atributos em Cliente. Em um sistema onde múltiplos clientes compartilham um endereço, ou onde endereços têm seu próprio ciclo de vida, Endereco deve ser uma entidade separada.

Sem consideração para exclusão suave. Muitos sistemas precisam reter registros após a "exclusão" por razões de auditoria ou regulatórias. Decida antecipadamente se usa um timestamp deletadoEm ou uma flag ativo, e aplique consistentemente.

Supernormalizar para conjuntos de dados pequenos. Extrair toda string repetida em uma tabela de referência adiciona complexidade sem benefício para conjuntos de dados que nunca crescerão além de milhares de linhas. Aplique julgamento, não regras mecânicas.

Ignorar o design de índices. O diagrama ER mostra estrutura, não desempenho. Após finalizar o schema, identifique as colunas que serão usadas em cláusulas WHERE e condições JOIN e adicione índices a elas.

Exemplo real: schema de e-commerce

O schema a seguir cobre as entidades principais de um sistema de e-commerce típico.

┌──────────────┐     ┌──────────────┐     ┌───────────────────┐
│   Cliente    │     │   Pedido     │     │   ItemPedido      │
│──────────────│     │──────────────│     │───────────────────│
│ PK id        │     │ PK id        │     │ PK id             │
│    email     │||─o<│ FK clienteId │||─|<│ FK pedidoId       │
│    primeiroNome│   │ FK enderecoId│     │ FK produtoId      │
│    ultimoNome│     │    status    │     │    quantidade     │
│    criadoEm  │     │    subtotal  │     │    precoUnitario  │
│    status    │     │    imposto   │     └────────┬──────────┘
└──────────────┘     │    frete     │              │
                     │    total     │         exatamente um
                     │    criadoEm  │              │
                     └──────────────┘     ┌────────┴──────────┐
                                          │      Produto      │
┌──────────────┐                          │───────────────────│
│   Endereco   │                          │ PK id             │
│──────────────│                          │ FK categoriaId    │
│ PK id        │                          │    nome           │
│ FK clienteId │                          │    descricao      │
│    linha1    │                          │    sku            │
│    linha2    │                          │    preco          │
│    cidade    │                          │    qtdEstoque     │
│    estado    │                          │    ativo          │
│    cep       │                          └────────┬──────────┘
│    pais      │                                   │
│    padrao    │                              muitos│ pertence a
└──────────────┘                                   │ um
                                          ┌────────┴──────────┐
┌──────────────┐                          │     Categoria     │
│   Pagamento  │                          │───────────────────│
│──────────────│                          │ PK id             │
│ PK id        │                          │ FK paiId          │
│ FK pedidoId  │                          │    nome           │
│    metodo    │                          │    slug           │
│    valor     │                          └───────────────────┘
│    status    │
│    processadoEm│
└──────────────┘

Principais decisões de design neste schema:

Endereco é uma entidade separada (clientes podem ter múltiplos endereços; pedidos referenciam o endereço usado no momento da compra)
ItemPedido.precoUnitario é armazenado separadamente de Produto.preco (preços mudam; o histórico de pedidos deve refletir o que foi cobrado)
Categoria tem um paiId auto-referenciante para categorias hierárquicas
Pagamento é separado de Pedido porque um pedido pode envolver múltiplas tentativas de pagamento

Criando diagramas ER com Flowova

Projetar um schema manualmente ou em um editor de texto simples é lento. O gerador de diagrama ER da Flowova permite que você descreva seu modelo de dados em linguagem simples e produz um diagrama estruturado para refinar. Comece com sua lista de entidades, descreva os relacionamentos entre elas e obtenha um schema visual para compartilhar com sua equipe para revisão.

Conclusão

Diagramas ER são a base de um bom design de banco de dados. Eles forçam você a ser explícito sobre quais dados o sistema armazena, o que torna cada registro único e como as entidades se relacionam entre si — antes que essas decisões se tornem caras de mudar em SQL. Comece no nível conceitual com entidades e relacionamentos, mova para o nível lógico adicionando atributos e resolvendo junções muitos-para-muitos, depois adicione tipos de dados e restrições para o design físico. Valide contra consultas reais, aplique normalização onde importa e documente o schema para que o próximo engenheiro possa entendê-lo sem ler os arquivos de migração.

Recursos relacionados

Símbolos de Fluxograma e Significados — Referência de notação padrão
Tipos de Fluxogramas — Quando usar diferentes tipos de diagrama
Guia de Diagrama de Sequência — Modelar interações de sistema
Gerador de Diagrama ER — Crie diagramas ER com IA