Início

Software Design

UA15 — Diagrama de Entidade e Relacionamento (DER)

O DER é a representação gráfica e conceitual da estrutura do banco de dados. É a 'planta baixa' do banco — independe de tecnologia e serve para alinhar o modelo com os requisitos de negócio antes de implementar.

Slides — Modelagem com DER

A Linha de Montagem do Arquiteto de Software
Fase 1 Conceitual (MER) → Fase 2 Lógico → Fase 3 Físico (SQL)
O Conceito Base: MER
O conceito base: MER
Entidades Físicas vs Lógicas
Entidades físicas vs. lógicas
Hierarquia de Entidades
Hierarquia de dependência
Atributos
Atributos: o raio-X do objeto
DER: O Desenho Formal
DER: o desenho formal da arquitetura
Notações
Peter Chen vs. Padrão UML
Fase 1: Abstraindo a Clínica Veterinária
Tutor, Animal e Veterinário — identificando entidades, atributos e relacionamentos

Elementos do DER

SímboloElementoRepresenta
RetânguloEntidadeObjeto do mundo real que precisa ser armazenado
ElipseAtributoCaracterística de uma entidade
Elipse sublinhadaAtributo-chave (PK)Identificador único da entidade
Elipse duplaAtributo multivaloradoPode ter múltiplos valores (ex.: telefones)
LosangoRelacionamentoAssociação entre entidades
Retângulo duploEntidade fracaDepende de outra para existir

Entidades Físicas vs. Lógicas

  • Físicas (Tangíveis): existem concretamente no mundo real. Ex.: Cliente, Produto, Funcionário, Fornecedor.
  • Lógicas (Conceituais): nascem da interação estrutural para organizar o negócio. Ex.: Venda, Matrícula, Agendamento, Contrato.

Hierarquia de dependência das entidades

  • Entidades Fortes: existem por si só. Ex.: Produto, Cliente.
  • Entidades Fracas: dependem de uma entidade forte para existir. Ex.: Dependente (de Funcionário) — sem o Funcionário, o Dependente não tem sentido.
  • Entidades Associativas: nascem da relação N:N para viabilizar relacionamentos complexos. Ex.: ItemPedido (entre Pedido e Produto).

Cardinalidades

Cardinalidades
Cardinalidade: a matemática do relacionamento
O Diagrama Entidade-Relacionamento (DER)
DER completo da clínica veterinária com cardinalidades

1:1 (Um para Um)

Cada instância de A se relaciona com no máximo uma de B. Ex.: Pessoa ↔ CPF, Presidente ↔ País.

1:N (Um para Muitos)

Uma instância de A se relaciona com várias de B. Ex.: Cliente → Pedidos, Departamento → Funcionários.

N:N (Muitos para Muitos)

Várias de A se relacionam com várias de B. Exige entidade associativa. Ex.: Pedido ↔ Produto.

MER vs. DER — distinção importante

MER (Modelo Entidade-Relacionamento)DER (Diagrama ER)
O que éModelo conceitual e abstratoRepresentação gráfica do MER
NívelConceitual — independe de tecnologiaLógico/físico — detalha tabelas e atributos
FocoEstrutura geral dos dadosEntidades, atributos, relacionamentos em diagrama
PropósitoComunicação entre equipe e clienteBase para implementação do banco

Notação de Peter Chen (original)

FiguraRepresenta
RetânguloEntidade
ElipseAtributo
LosangoRelacionamento
”1” e “N” ao lado das entidadesCardinalidade

Problema: fica visualmente poluído em sistemas com muitas tabelas. Por isso, usa-se hoje a notação UML, com atributos dentro do retângulo da entidade.

Passos para criar um DER

  1. Estudar e compreender o negócio do cliente (levantamento de requisitos).
  2. Identificar as entidades necessárias (ex.: clínica → Cliente, Médico, Remédio, Funcionário, Fornecedor).
  3. Definir os atributos de cada entidade e marcar chaves primárias.
  4. Estabelecer os relacionamentos entre entidades (verbo de ação: “cliente agenda consulta”).
  5. Definir a cardinalidade de cada relacionamento (1:1, 1:N, N:N).
  6. Identificar se há necessidade de entidade associativa (relacionamentos N:N).

Exemplo de DER — Loja Virtual

Entidade ARelacionamentoCardinalidadeEntidade B
Clienterealiza1:NPedido
PedidocontémN:NProduto
Relacionamento N:N → entidade associativa ItemPedido (quantidade, preco_unitario)

Práticas Modernas — DER e Modelagem de Banco

  • Ferramentas modernas para DER: dbdiagram.io (texto para ER), DrawDB, Lucidchart e DBeaver (DER reverso a partir de banco existente). Figma também é usado para DER conceituais em equipes de produto.
  • ORMs code-first (Prisma schema, Entity Framework, TypeORM) invertem o fluxo: você define entidades em código e a ferramenta gera o DER e as migrations — o diagrama conceitual emerge do modelo de código.
  • Database branching (PlanetScale, Neon) permite criar branches de schema para desenvolvimento — igual a branches de código, sem impactar produção. O DER “diverge” e depois “merge” com revisão de alterações.
  • NoSQL e esquemas flexíveis: MongoDB (documentos), Redis (chave-valor), Neo4j (grafos) e Cassandra (colunar) resolvem problemas onde o modelo relacional é ineficiente — o DER clássico não se aplica.

Dicas para a prova — UA15

  • DER Peter Chen: entidades = retângulos; atributos = elipses; relacionamentos = losangos. (Afirmação “entidades = losangos” é FALSA.)
  • O DER é correto quando representa entidades, atributos e relacionamentos antes da implementação — facilita identificar erros.
  • Chave primária: garante unicidade, não aceita nulos, não aceita valores repetidos. Pode ser composta.
  • Relacionamento N:N: uma entidade pode se relacionar com várias instâncias da outra e vice-versa — exige tabela intermediária.
  • MER = conceitual (abstrato); DER = representação gráfica do MER (lógico/físico).

Referências bibliográficas desta UA

  • Barboza, F. F. M. Modelagem e Desenvolvimento de Banco de Dados. Porto Alegre: SAGAH, 2018.
  • Rodrigues, J. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). DevMedia, 2014.