Gerador de Diagrama ER (Mermaid)

Diagramas ER: do artigo de Chen em 1976 à notação pé-de-galinha moderna

Um diagrama Entidade-Relacionamento (ER) é a língua franca da modelagem conceitual de dados. Introduzido por Peter Chen no artigo seminal de 1976 "The Entity-Relationship Model — Toward a Unified View of Data", ele deu aos projetistas de banco de dados um vocabulário visual para descrever quais informações um sistema armazena e como as partes se relacionam, independente de qualquer SGBD ou layout físico. Cinquenta anos depois, diagramas ER ainda guiam toda discussão séria de modelagem — do rascunho de quadro branco do primeiro dia aos diagramas gerados automaticamente por Prisma, dbdiagram.io ou MySQL Workbench.

Este gerador emite um esboço ER limpo que pode ser colado no Mermaid, no DBML do dbdiagram.io ou em uma apresentação. Abaixo está a referência completa: os símbolos originais de Chen, a notação pé-de-galinha (mais popular), regras de cardinalidade, normalização, entidades fracas vs fortes, hierarquias ISA e como manter o diagrama sincronizado com o banco real.

Componentes originais de Chen

• Entidade — algo de interesse do negócio, desenhado como um retângulo. Exemplos: Usuario, Pedido, Produto, NotaFiscal.
• Atributo — uma propriedade da entidade, desenhada como uma elipse ligada ao retângulo. Exemplos: nome, email, preco.
• Relacionamento — um verbo conectando entidades, desenhado como um losango. Exemplos: faz (Usuario-Pedido), contém (Pedido-Item).
• Identificador / Chave — atributo (ou conjunto de atributos) que identifica unicamente uma linha, desenhado com sublinhado.
• Atributo derivado (elipse tracejada), multivalorado (elipse dupla), composto (elipse com sub-elipses).

Notação pé-de-galinha: o padrão moderno

A maioria das ferramentas atuais (dbdiagram.io, drawSQL, Lucidchart, MySQL Workbench, ERWin) usa a variante pé-de-galinha (crow's-foot). Cada entidade vira um retângulo com seus atributos listados em linha, e a linha entre duas entidades termina em símbolos descrevendo a cardinalidade em cada ponta:

• | — exatamente um (obrigatório).
• o — zero (opcional).
• >— ou —< — o "pé-de-galinha": muitos.
• Combinações: |o = zero ou um, || = exatamente um, }o = zero ou muitos, }| = um ou muitos.

O bloco erDiagram do Mermaid usa versões ASCII desses símbolos:

erDiagram
  CLIENTE ||--o{ PEDIDO : faz
  PEDIDO  ||--|{ ITEM   : contem
  PEDIDO  }o--|| ENDERECO : entrega-em
  CLIENTE {
    int    id PK
    string nome
    string email "unique"
  }

Cardinalidade: 1:1, 1:N e N:N

• 1:1 — raro. Frequentemente é sinal de que duas entidades deveriam ser unidas, ou que você está particionando verticalmente uma tabela larga (ex: Usuario e PerfilUsuario).
• 1:N — o relacionamento mais comum. Um Cliente faz muitos Pedidos; um Pedido pertence a exatamente um Cliente. Implementado com chave estrangeira do lado "muitos".
• N:N — resolvido com uma tabela de junção (também chamada de tabela associativa ou ponte). Aluno × Disciplina vira Matricula, com FKs para ambas e atributos opcionais (nota, data) próprios.

Entidades fortes vs fracas e hierarquias ISA

Uma entidade forte tem identificador próprio (Pedido.id). Uma entidade fraca não pode ser identificada apenas pelos seus atributos e depende de uma entidade "dona" — por exemplo ItemPedido com (pedido_id, numero_linha) como chave composta. Em diagramas pé-de-galinha, a entidade fraca tem borda dupla e o relacionamento identificador é desenhado com losango duplo.

ISA / generalização / especialização modela herança: Pessoa pode ser especializada em Aluno e Professor, compartilhando atributos comuns e adicionando os próprios. Na implementação física isso vira class table inheritance, single table inheritance ou joined inheritance — o diagrama conceitual deixa a escolha para depois.

Normalização: de 1FN a BCNF

Uma vez que o diagrama ER existe, a normalização indica se as tabelas resultantes evitam anomalias:

• 1FN — toda coluna contém valor atômico, sem grupos repetidos nem arrays em colunas.
• 2FN — toda coluna não-chave depende da chave primária inteira (relevante para chaves compostas).
• 3FN — sem dependências transitivas (coluna não-chave dependendo de outra não-chave).
• BCNF — 3FN mais rigorosa, em que todo determinante é chave candidata.
• 4FN / 5FN — eliminam dependências multivaloradas e de junção; raramente necessárias em OLTP.

Conceitual, lógico e físico

A maioria dos times itera em três níveis de detalhe: conceitual (nomes de entidade + relacionamentos, sem tipos), lógico (atributos com tipos, chaves, normalização aplicada, ainda agnóstico de SGBD) e físico (PostgreSQL VARCHAR(255), MySQL BIGINT UNSIGNED, índices, partições, views materializadas). Use o diagrama conceitual para alinhar com produto, o lógico para engenheiros e o físico para DBAs e DevOps.

FAQ

Diagrama ER vs diagrama de classes UML — qual a diferença? UML descreve designs orientados a objetos (métodos, herança, visibilidade); ER descreve dados relacionais (entidades, atributos, cardinalidade). Há sobreposição, mas falam com públicos distintos — backend usa UML, DBA usa ER.

Quanto detalhe um diagrama ER deve mostrar? Comece conceitual (apenas caixas e verbos) para alinhar stakeholders e enriqueça com atributos e tipos só quando o schema estabilizar. Colocar toda coluna nullable no diagrama de dia um o torna ilegível.

Como manter o diagrama sincronizado com o banco real? Use ferramentas que geram o diagrama a partir do schema, e não o contrário: prisma-erd-generator, SchemaSpy, Atlas ou schemahero. Um diagrama mantido à mão sai de sincronia em dias.

Preciso resolver todo N:N antes de desenhar? Não — no estágio conceitual você pode deixar Aluno }o--o{ Disciplina como muitos-para-muitos. Ao migrar para o modelo lógico, introduza a tabela de junção.

Quais ferramentas usar para desenhar? dbdiagram.io e DBML para diagramas baseados em texto, drawSQL para uma UI web polida, MySQL Workbench / pgModeler para ida e volta com banco real, Mermaid para diagramas que vivem em Markdown e Git.