SQL para ERD

Cole uma ou mais instruções CREATE TABLE e esta ferramenta desenha o esquema: cada tabela torna-se uma entidade, as colunas tornam-se atributos marcados com PK / FK, e as restrições FOREIGN KEY tornam-se linhas de relação. Quando um esquema não declara chaves estrangeiras, colunas como customer_id são oferecidas como relações inferidas que pode manter ou descartar. Copie a fonte Mermaid erDiagram ou exporte o diagrama como SVG / PNG. Tudo corre localmente — nenhum esquema sai do seu navegador.
O que é um ERD? ERD significa Entity Relationship Diagram (diagrama entidade-relação) — uma imagem de como uma base de dados está organizada. É desenhado a partir de três tipos de formas: entidades (as tabelas, desenhadas como caixas), atributos (as colunas listadas dentro de uma caixa) e relações (as linhas que unem duas caixas). A técnica vem do modelo entidade-relação de Peter Chen, de 1976, e continua a ser a forma habitual de esboçar um esquema antes de escrever qualquer DDL: um bom ERD mostra de relance que tabelas existem, o que guarda cada linha e como uma linha de uma tabela aponta para uma linha de outra — legível por quem não quer ler SQL.
Entity — one thing the system keeps data about, such as a customer, an order or a product. In a relational database each entity becomes one table.
Attribute — one fact recorded for every row of an entity, such as a name, a price or a date. Each attribute becomes one column.
Relationship — an association between two entities, implemented by a foreign key: the child table stores the parent’s key, and the diagram turns that column into a line.
PK / FK — a primary key (PK) identifies each row of a table uniquely; a foreign key (FK) holds the primary key of another table and is what a relationship line represents.
Cardinalidade — quantas linhas são permitidas em cada extremidade de uma linha: um-para-um, um-para-muitos ou muitos-para-muitos. Esta página desenha a notação de pé de galinha que o Mermaid usa (veja a legenda no passo 4).
Notações: a notação de Chen usa losangos para as relações e elipses para os atributos; a notação de pé de galinha (a desenhada aqui) comprime uma entidade numa única caixa com os seus atributos listados por dentro e marca a extremidade “muitos” de uma linha com um “pé de galinha” de três pontas; os diagramas de classes UML descrevem a mesma estrutura com classes, operações e multiplicidades. As três dizem o mesmo sobre o esquema — só os símbolos diferem.
1 — Esquema das tabelas (DDL)
2 — Entidades
Desenhar Tabela Colunas Relações Atributos
Ainda sem tabelas analisadas.
3 — Relações
Usar Filho (muitos) Actions Pai (um) Fonte Actions
Ainda sem relações.
Adicione uma relação manualmente:
→
4 — Diagrama
Fonte Mermaid erDiagram
Como se leem as relações: uma chave estrangeira na tabela filha produz PAI ||--o{ FILHO. As entidades e os atributos mantêm os nomes do DDL, e os caracteres que o Mermaid não consegue desenhar (espaços, traços) são mostrados como sublinhados. Os tipos são simplificados à sua palavra-base (DECIMAL(10,2) → DECIMAL), porque a sintaxe do diagrama não aceita parâmetros.
Símbolos de cardinalidade (pé de galinha): a marca junto a uma entidade indica quantas linhas podem estar nessa extremidade da linha — || exatamente uma, o| zero ou uma, o{ zero ou muitas, |{ uma ou muitas. Assim, PAI ||--o{ FILHO lê-se como “uma linha pai pode ser referenciada por zero, uma ou muitas linhas filhas, e cada linha filha aponta para exatamente uma pai” — a ligação clássica um-para-muitos.
Many-to-many is never a single line: a product can appear in many orders and an order can hold many products, so the schema stores a join table (order_items) whose two foreign keys become two one-to-many lines. Read through that middle box and the many-to-many is there.