erDiagram
LIVRO {
string isbn
string titulo
int ano_publicacao
}
AUTOR {
int id_autor
string nome
string nacionalidade
}
Modelo Entidade-Relacionamento e Diagramas (DER)
Quero começar este módulo te dando uma boa notícia: se você entendeu, nos módulos anteriores, por que um banco de dados precisa ser bem estruturado, então você já tem a motivação certa para o que vamos estudar agora. O Modelo Entidade-Relacionamento, que vou chamar pela sigla MER ao longo do texto, é a ferramenta que usamos para pensar o banco antes de criá-lo. Repare comigo: ninguém constrói uma casa começando pela fiação elétrica; primeiro vem a planta. O MER é exatamente a planta do nosso banco de dados, e o Diagrama Entidade-Relacionamento (o DER) é o desenho dessa planta. Esse tema cai com frequência em prova porque ele separa quem decora comandos SQL de quem realmente entende como os dados se organizam. Vou te mostrar cada peça com calma, com diagramas em abundância, para que ao final você consiga olhar para um problema do mundo real e enxergar as entidades e relacionamentos quase que automaticamente.
O MER foi proposto por Peter Chen em 1976 e, mesmo depois de quase cinco décadas, continua sendo a abordagem mais popular para a chamada modelagem conceitual. Conceitual é uma palavra importante aqui: significa que estamos descrevendo o que o sistema precisa armazenar, sem nos preocuparmos ainda com tabelas, tipos de coluna do PostgreSQL ou índices. É uma ponte entre o mundo real — onde existem alunos, pedidos, contas bancárias — e o mundo dos dados estruturados. No módulo 05 vamos atravessar essa ponte de fato, transformando o DER em tabelas concretas. Por ora, o nosso compromisso é desenhar bem.
Entidades: as coisas que importam no domínio
Uma entidade é um objeto ou conceito do mundo real sobre o qual desejamos guardar informações. Gosto de pensar nela como uma “coisa distinguível” dentro do contexto que estou modelando. Entidades podem ser concretas, como uma pessoa, um carro ou um livro, ou abstratas, como uma transação, um curso ou um evento. O detalhe que muita gente confunde é a diferença entre o tipo de entidade e a instância. Quando digo que Livro é uma entidade, estou falando do conjunto, do molde; cada livro específico na prateleira da biblioteca é uma instância desse molde.
Para algo ser uma boa entidade, eu costumo cobrar três características. A primeira é a identificação única: cada instância precisa ser distinguível das demais do mesmo tipo, senão não conseguimos sequer guardá-la de forma confiável. A segunda é possuir atributos, ou seja, propriedades que a descrevem. A terceira, e talvez a mais sutil em prova, é a independência de existência: uma entidade verdadeira existe por si só, não sendo totalmente dependente de outra para fazer sentido. Guarde esse critério da independência, porque ele vai reaparecer quando discutirmos entidades fracas.
Vou ancorar tudo num exemplo que carregaremos pelo módulo inteiro: um sistema de biblioteca. Nele, Livro, Autor, Exemplar e Emprestimo são candidatos naturais a entidades.
Definição — Entidade. É um conjunto de objetos ou conceitos do mundo real, distinguíveis entre si, sobre os quais o sistema precisa armazenar dados. Cada ocorrência concreta desse conjunto é chamada de instância (ou ocorrência) da entidade.
Atributos: as propriedades que descrevem
Se a entidade é a coisa, os atributos são as características dessa coisa. Para a entidade Livro, atributos óbvios são ISBN, título, autor, ano de publicação. O ponto que a prova adora explorar é que nem todo atributo é igual: existe uma classificação que você precisa dominar. Vou apresentá-la com cuidado porque cada tipo tem uma consequência prática lá na frente, no mapeamento para tabelas.
Um atributo simples é aquele que não pode ser subdividido de forma útil — o título de um livro é um bom exemplo. Um atributo composto pode ser quebrado em subpartes que têm significado próprio; o caso clássico é endereco, que se decompõe em rua, número, cidade, estado e CEP. Um atributo multivalorado é aquele que admite vários valores para uma mesma instância: pense nos telefones de uma pessoa, que podem ser dois, três ou mais. Por fim, um atributo derivado é aquele cujo valor pode ser calculado a partir de outros e que, por isso, idealmente nem precisamos armazenar. O exemplo perfeito é a idade, que se obtém da data de nascimento e da data atual.
erDiagram
PESSOA {
int id_pessoa
string nome
string endereco_rua
string endereco_cidade
string endereco_estado
date data_nascimento
}
Note que no diagrama acima eu já “achatei” o endereço composto em três campos e deixei de fora a idade derivada — é assim que esses atributos especiais tendem a aparecer quando saímos do conceitual para o lógico. Em SQL, um atributo derivado costuma virar um cálculo, não uma coluna:
| Tipo de atributo | Pode subdividir? | Admite vários valores? | Exemplo |
|---|---|---|---|
| Simples | Não | Não | título do livro |
| Composto | Sim | Não | endereço |
| Multivalorado | Não | Sim | telefones |
| Derivado | Depende | Não | idade |
Atenção. Atributos multivalorados e compostos não existem de forma nativa no modelo relacional puro. Quando chegarmos ao módulo 05, você verá que o multivalorado normalmente vira uma tabela separada, e o composto se desmembra em várias colunas. Reconhecer esses tipos já no DER evita modelagens problemáticas mais tarde.
Chaves: como identificar cada instância
Chegamos a um conceito que sustenta todo o resto. Uma chave é um atributo, ou um conjunto de atributos, que identifica unicamente cada instância de uma entidade. Sem chave, não há como dizer com certeza “este registro é diferente daquele”, e o banco perde a confiabilidade.
A chave primária é a escolhida oficialmente para identificar cada instância — ela é única e não pode ser nula. A chave candidata é qualquer atributo (ou conjunto) que poderia desempenhar esse papel; entre as candidatas, escolhemos uma para ser a primária, e as demais permanecem como alternativas únicas. A chave estrangeira é diferente em natureza: ela é um atributo de uma entidade que aponta para a chave primária de outra, e é justamente ela que materializa os relacionamentos no banco relacional. No nosso Livro, o ISBN é uma excelente chave primária, pois é único por definição internacional.
Definição — Chaves. Chave candidata é qualquer conjunto mínimo de atributos capaz de identificar unicamente uma instância. A chave primária é a candidata eleita para esse papel. A chave estrangeira é um atributo que referencia a chave primária de outra entidade, garantindo a integridade referencial entre elas.
Domínios e restrições: garantindo dados sãos
Antes de seguir para os relacionamentos, preciso te apresentar dois conceitos que parecem secundários mas pesam na prova. O domínio de um atributo é o conjunto de valores possíveis que ele pode assumir. Definir domínios é a primeira linha de defesa da integridade dos dados. O domínio do atributo ano_publicacao de um livro, por exemplo, poderia ser razoavelmente restrito a inteiros entre 1450 — quando Gutenberg inventou a prensa de tipos móveis — e o ano corrente.
As restrições são as regras que o banco deve sempre obedecer. Eu gosto de classificá-las em quatro grandes grupos. As restrições de domínio limitam os valores de um atributo. As restrições de chave garantem a unicidade. As restrições de integridade referencial asseguram que toda chave estrangeira aponte para uma instância existente. E as restrições de integridade de entidade exigem que toda instância seja unicamente identificável, o que se traduz na regra de que a chave primária nunca pode ser nula.
Relacionamentos: como as entidades conversam
Entidades isoladas não formam um sistema interessante; o que dá vida ao modelo são os relacionamentos. Um relacionamento representa uma associação entre duas ou mais entidades, descrevendo como elas interagem no domínio. Entre Livro e Autor existe o relacionamento “escrito por”. Entre Leitor e Exemplar existe “toma emprestado”. Repare que costumo nomear relacionamentos com verbos — isso não é capricho, é boa prática que facilita a leitura do diagrama.
Três características governam um relacionamento. A cardinalidade indica quantas instâncias de uma entidade podem se associar a uma instância da outra. A participação diz se ela é total (obrigatória, toda instância participa) ou parcial (opcional). E há, em alguns casos, atributos do próprio relacionamento, que não pertencem a nenhuma das entidades isoladamente. O exemplo perfeito é a data e a nota de um empréstimo: a data em que o livro foi emprestado não é propriedade do livro nem do leitor, e sim do encontro entre os dois.
erDiagram
AUTOR ||--o{ LIVRO : escreve
LEITOR ||--o{ EMPRESTIMO : realiza
EXEMPLAR ||--o{ EMPRESTIMO : refere
LIVRO ||--o{ EXEMPLAR : possui
A cardinalidade aparece em três grandes padrões, e você precisa reconhecê-los de imediato. No um-para-um (1:1), cada instância de A se associa a no máximo uma de B e vice-versa — um país e sua capital, por exemplo. No um-para-muitos (1:N), uma instância de A se associa a várias de B, mas cada B se liga a apenas uma A — um autor que escreve vários livros, supondo autoria única. No muitos-para-muitos (N:M), instâncias de ambos os lados se associam livremente — um livro com vários autores e um autor com vários livros.
erDiagram
PAIS ||--|| CAPITAL : tem
DEPARTAMENTO ||--o{ FUNCIONARIO : emprega
ALUNO }o--o{ DISCIPLINA : cursa
| Cardinalidade | Símbolo Mermaid | Exemplo |
|---|---|---|
| Um para um | \|\|--\|\| |
país e capital |
| Um para muitos | \|\|--o{ |
departamento e funcionários |
| Muitos para muitos | }o--o{ |
alunos e disciplinas |
Atenção. Relacionamentos muitos-para-muitos não podem ser implementados diretamente no modelo relacional. Eles exigem uma entidade associativa (ou tabela de junção) que carrega as duas chaves estrangeiras. Vamos detalhar essa decomposição no módulo 04, mas já adianto que Matricula entre Aluno e Disciplina é o exemplo canônico, e que os atributos do relacionamento — como a nota final — encontram nessa entidade associativa o seu lugar.
Falando em participação, vale visualizar a diferença entre total e parcial. Quando digo que a participação de Emprestimo em relação a Leitor é total, estou afirmando que todo empréstimo obrigatoriamente pertence a um leitor — não existe empréstimo sem dono. Já a participação de Leitor pode ser parcial, porque existem leitores cadastrados que nunca pegaram nada emprestado.
Entidades fortes e fracas
Agora aquela ideia de independência volta a importar. Uma entidade forte tem existência própria e possui atributos suficientes para formar sua própria chave primária. Uma entidade fraca, ao contrário, depende da existência de outra entidade — a chamada entidade proprietária — para ser identificada. Ela não tem atributos que, sozinhos, formem uma chave primária, e por isso toma emprestada a chave da proprietária, combinando-a com um atributo seu (a chave parcial ou discriminadora).
Um exemplo bancário esclarece bem. Conta é forte: tem número próprio e existe por si. Transacao tende a ser fraca: um sequencial de transação só faz sentido dentro de uma conta específica. A transação número 5 da conta A é completamente diferente da transação número 5 da conta B; é a conta que dá identidade à transação.
erDiagram
CONTA ||--o{ TRANSACAO : registra
CONTA {
int numero_conta
decimal saldo
}
TRANSACAO {
int seq_transacao
decimal valor
date data
}
Note no diagrama que seq_transacao sozinho não identifica nada; ele só ganha sentido junto de numero_conta. No módulo 05 você verá que a chave primária da tabela de transações combina as duas colunas.
Definição — Entidade forte e fraca. Entidade forte possui chave primária própria e existência independente. Entidade fraca depende de uma entidade proprietária para sua identificação, formando sua chave a partir da chave da proprietária somada a um atributo discriminador. Toda entidade fraca participa de um relacionamento identificador, sempre com participação total.
Generalização e especialização
Há momentos em que percebemos que várias entidades compartilham um núcleo comum de atributos. Quando abstraímos esse núcleo numa entidade mais genérica, fazemos generalização; quando partimos da genérica e a dividimos em subtipos mais específicos, fazemos especialização. São dois caminhos para a mesma estrutura hierárquica de supertipo e subtipos, e a diferença está apenas no sentido do raciocínio.
O exemplo clássico é o de Veiculo como supertipo, especializado em Carro, Moto e Caminhao. Os atributos comuns — placa, cor, ano — ficam no supertipo; os específicos, como número de eixos do caminhão, ficam no subtipo correspondente. Essa hierarquia ainda admite duas decisões importantes que você verá com mais profundidade adiante: ela pode ser total (todo veículo é obrigatoriamente de algum subtipo) ou parcial, e pode ser exclusiva, também chamada disjunta (cada instância pertence a um único subtipo), ou sobreposta (pode pertencer a mais de um).
erDiagram
VEICULO ||--o| CARRO : eh
VEICULO ||--o| MOTO : eh
VEICULO ||--o| CAMINHAO : eh
VEICULO {
string placa
string cor
int ano
}
Definição — Generalização e especialização. Generalização agrupa entidades semelhantes sob um supertipo comum; especialização desdobra um supertipo em subtipos. A herança transmite os atributos e relacionamentos do supertipo aos subtipos. As decisões de totalidade e disjunção determinam como essa hierarquia será mapeada para tabelas.
A notação do DER e como construir um
Até aqui usei o estilo de diagrama ER do Mermaid, que é prático e legível. Mas em prova você precisa conhecer as notações clássicas. A notação de Chen, a original, representa entidades como retângulos, relacionamentos como losangos e atributos como elipses ligadas por linhas, com a cardinalidade escrita como números ou letras sobre as linhas. É a mais didática e a que mais aparece em contextos acadêmicos, justamente por explicitar cada elemento como uma figura distinta.
A notação Pé de Galinha (Crow’s Foot) é a preferida das ferramentas modernas: entidades viram retângulos com os atributos listados dentro, os relacionamentos são as próprias linhas, e a cardinalidade é desenhada por símbolos nas pontas — o tracinho para “um”, o circulozinho para “zero” (opcional) e o pezinho de galinha de três traços para “muitos”. Há ainda a notação de Martin, ou de Engenharia da Informação, parecida com a Pé de Galinha e hoje menos comum. A tabela abaixo sintetiza as diferenças que mais caem.
| Elemento | Chen | Pé de Galinha |
|---|---|---|
| Entidade | retângulo | retângulo |
| Atributo | elipse ligada por linha | listado dentro da entidade |
| Relacionamento | losango | a própria linha |
| Cardinalidade | números ou letras (1, N, M) | símbolos nas pontas |
Sobre o processo de construção, eu sigo uma sequência que funciona bem e que vale memorizar como um pequeno algoritmo:
- Identifique as entidades, varrendo os requisitos em busca de substantivos relevantes e classificando cada uma como forte ou fraca.
- Defina os atributos de cada entidade, classificando-os e elegendo a chave primária.
- Estabeleça os relacionamentos, determinando cardinalidade, participação e eventuais atributos próprios.
- Aplique generalizações e especializações onde houver hierarquias, decidindo totalidade e disjunção.
- Refine o diagrama, validando contra as regras de negócio e eliminando redundâncias.
- Documente, anotando o que não couber no desenho e preparando um glossário de termos.
Uma técnica que sempre recomendo na primeira etapa é o exercício de sublinhar substantivos e verbos no enunciado: os substantivos costumam virar entidades ou atributos, e os verbos costumam virar relacionamentos. “O leitor pega emprestado um exemplar de livro” já te entrega quase todo o modelo da biblioteca.
flowchart TD
A[Analisar requisitos] --> B[Identificar entidades]
B --> C[Definir atributos e chaves]
C --> D[Estabelecer relacionamentos]
D --> E[Aplicar generalizacao e especializacao]
E --> F[Refinar e validar]
F --> G[Documentar]
F -.revisao iterativa.-> B
Esse diagrama de fluxo carrega uma mensagem que considero essencial: a modelagem é iterativa. Aquela seta tracejada voltando para o início não é enfeite. É comum descobrir, ao estabelecer relacionamentos, que faltou uma entidade, ou que um suposto atributo era na verdade uma entidade independente.
Boas práticas e ferramentas
Modelar bem é tanto técnica quanto disciplina visual. Eu cobro de mim alguns princípios. Clareza e simplicidade: mantenha o diagrama enxuto, sem perder o essencial. Consistência: use a mesma notação do começo ao fim e um padrão único de nomes — eu prefiro substantivos no singular para entidades e verbos para relacionamentos. Nomeação significativa, fugindo de abreviações ambíguas. Legibilidade, evitando ao máximo o cruzamento de linhas, que transforma qualquer DER num emaranhado ilegível. E validação com os interessados, porque um modelo lindo que não reflete a regra de negócio é um modelo errado.
Quanto às ferramentas, há várias. Para fins gerais existem o Lucidchart, o Draw.io e o Microsoft Visio. Para modelagem voltada a banco existe o MySQL Workbench e o ERDPlus. No nosso contexto de PostgreSQL, a ferramenta que mais recomendo é o pgModeler: ele é específico para Postgres, trabalha em notação Pé de Galinha, e tem um diferencial poderoso — gera o script SQL de criação a partir do diagrama e faz o caminho inverso, lendo um banco existente e desenhando o DER. Isso te dá um laço completo entre o desenho e o banco real, exatamente a ponte que cruzaremos no módulo 05.
Vale lembrar das limitações do DER, que também aparecem em prova. Ele pode ficar difícil de manejar em sistemas muito grandes, não representa bem aspectos temporais ou históricos, foca na estrutura dos dados e não nos processos de negócio, tem dificuldade com restrições muito complexas e não é a melhor ferramenta para dados semiestruturados ou não estruturados. Reconhecer esses limites não diminui o DER; apenas o coloca no seu devido lugar, que é a modelagem conceitual de dados estruturados.
Síntese para a prova. Domine a tríade entidade, atributo e relacionamento, e saiba distinguir tipo de instância. Memorize os quatro tipos de atributo — simples, composto, multivalorado e derivado — porque cada um tem destino diferente no mapeamento. Tenha as chaves na ponta da língua: candidata, primária e estrangeira, lembrando que a estrangeira é quem implementa os relacionamentos e que a integridade de entidade proíbe chave primária nula. Saiba ler cardinalidades 1:1, 1:N e N:M, e tenha claro que o N:M sempre exige entidade associativa no relacional. Entenda participação total versus parcial. Reconheça a entidade fraca pela dependência identificadora da proprietária. Saiba que generalização e especialização são o mesmo eixo em sentidos opostos, com decisões de totalidade e disjunção. E, na parte de notação, não confunda Chen — losangos e elipses — com Pé de Galinha — atributos dentro do retângulo e símbolos de cardinalidade nas pontas. Se você consolidar esses pontos, terá uma base firme para os módulos 04 e 05, onde aprofundamos relacionamentos complexos e o mapeamento para tabelas.