Exemplos de Diagramas Entidade-Relacionamento: Um Guia Visual para Desenvolvedores

Diagramas Entidade-Relacionamento (ERDs) são a linguagem universal do design de banco de dados. Eles permitem que você veja a estrutura completa de um banco de dados de relance — cada tabela, cada coluna, cada relacionamento — antes de escrever uma única linha de SQL. Mas para muitos desenvolvedores, a melhor forma de aprender a criar diagramas ER é estudar exemplos concretos e do mundo real.

Neste guia, percorremos cinco exemplos práticos de diagramas ER em diferentes domínios. Para cada um, descrevemos as tabelas, as colunas principais e os relacionamentos entre elas. Ao final, você será capaz de ler qualquer diagrama ER fluentemente e projetar o seu próprio do zero.

O que é um Diagrama ER?

Um diagrama ER é um mapa visual de um banco de dados relacional. Ele mostra entidades (tabelas), atributos (colunas) e relacionamentos (chaves estrangeiras). Cada caixa no diagrama representa uma tabela; cada linha conectando duas caixas representa um relacionamento entre elas. Os símbolos em cada extremidade da linha descrevem a cardinalidade — se o relacionamento é um-para-um, um-para-muitos ou muitos-para-muitos.

Tipos de Notação: Chen vs. Crow's Foot

Duas notações dominam os diagramas ER modernos. A notação de Chen, inventada por Peter Chen em 1976, usa retângulos para entidades, ovais para atributos e losangos para relacionamentos. É academicamente rigorosa, mas verbosa, tornando schemas grandes difíceis de ler.

A notação Crow's Foot é usada por virtualmente todas as ferramentas modernas de design de banco de dados, incluindo ER Flow. As entidades são retângulos com colunas listadas dentro. Os relacionamentos são linhas com pequenos símbolos em cada extremidade: uma barra vertical única significa "um", um crow's foot (três linhas espalhadas) significa "muitos" e um círculo significa "zero". Esta notação compacta facilita o mapeamento de schemas grandes em um único canvas.

Exemplo 1: Plataforma de E-Commerce

Um schema de e-commerce tipicamente gira em torno de cinco tabelas principais. A tabela users armazena contas de clientes com colunas como id, email, password_hash, name e created_at. A tabela products contém o catálogo: id, name, description, price, stock_quantity e category_id. A tabela categories fornece uma hierarquia simples com id, name e um parent_id nullable com chave estrangeira auto-referenciada para subcategorias.

A tabela orders liga clientes a compras: id, user_id (FK para users), status, total_amount e created_at. Finalmente, a tabela de junção order_items captura os itens de linha de cada pedido: id, order_id (FK para orders), product_id (FK para products), quantity e unit_price. O relacionamento lê-se: um usuário tem muitos pedidos; um pedido tem muitos itens de pedido; cada item de pedido referencia um produto.

Exemplo 2: Plataforma de Blog

Um schema de blog é um exemplo clássico de ensino porque demonstra vários tipos de relacionamento de forma limpa. A tabela users armazena autores. A tabela posts tem id, user_id (FK), title, slug, body, published_at e status. Uma tabela comments adiciona id, post_id (FK), user_id (FK), body e created_at — um relacionamento de um post tem muitos comentários. Para tagueamento, uma tabela tags (id, name, slug) e uma tabela de junção post_tags (post_id, tag_id) implementam um relacionamento muitos-para-muitos entre posts e tags.

Exemplo 3: Autenticação de Usuários SaaS

Aplicações SaaS modernas precisam de mais do que uma tabela users. Um schema de autenticação de nível produção tipicamente inclui users (id, email, password_hash, email_verified_at, created_at), personal_access_tokens (id, tokenable_id, tokenable_type, name, token, last_used_at, expires_at) para tokens de API, e password_reset_tokens (email, token, created_at). Para login OAuth, uma tabela oauth_accounts liga IDs de provedores externos a usuários locais: id, user_id (FK), provider, provider_id, access_token, refresh_token.

Exemplo 4: Ferramenta de Gerenciamento de Projetos

Um schema de gerenciamento de projetos é centrado em workspaces, projetos e tarefas. A tabela workspaces (id, name, owner_id) é o container de nível superior. projects (id, workspace_id FK, name, description, status) pertencem a workspaces. tasks (id, project_id FK, assignee_id FK para users, title, description, status, due_date, position) pertencem a projetos. Uma tabela de junção workspace_members (workspace_id, user_id, role) implementa o relacionamento muitos-para-muitos entre usuários e workspaces com uma coluna role (owner, admin, member) anexada ao join.

Exemplo 5: Sistema de Gestão Hospitalar

Schemas hospitalares ilustram relacionamentos mais complexos. patients (id, name, date_of_birth, blood_type, contact_info) armazenam dados demográficos. doctors (id, user_id FK, specialty, license_number) estendem a tabela de usuários. appointments (id, patient_id FK, doctor_id FK, scheduled_at, status, notes) criam uma ponte muitos-para-muitos entre pacientes e médicos ao longo do tempo. medical_records (id, patient_id FK, doctor_id FK, diagnosis, treatment, recorded_at) armazenam histórico clínico. prescriptions (id, record_id FK, medication_name, dosage, instructions) pertencem a registros médicos.

Como Ler um Diagrama ER

Comece varrendo os nomes das tabelas para entender o domínio. Em seguida, olhe para os relacionamentos — trace cada linha de uma tabela para outra e leia os símbolos de cardinalidade. Uma linha de users para orders com uma única barra na extremidade de users e um crow's foot na extremidade de orders lê-se: "um usuário tem muitos pedidos." Finalmente, examine os nomes e tipos das colunas para entender quais dados são armazenados. Colunas de chave estrangeira (user_id, order_id) tornam as colunas de relacionamento imediatamente óbvias.

Construindo Diagramas ER com ER Flow

ER Flow é construído especificamente para criar diagramas ER exatamente como os descritos neste artigo. Você pode adicionar tabelas visualmente, definir colunas com tipos e restrições e desenhar relacionamentos conectando tabelas com um arrasto. A notação Crow's Foot é renderizada automaticamente. Quando seu design estiver pronto, ER Flow gera arquivos de migration SQL — para que o diagrama e o schema real do banco de dados estejam sempre sincronizados. Seja projetando do zero ou fazendo engenharia reversa de um banco de dados existente, ER Flow torna o processo rápido e colaborativo.