电商 ER 图. Copy the source, paste into the official playground, done. No coordinates — every position is stated relative to something else.
node users "users"
node orders "orders" right of users
node products "products" right of orders
node items "order_items" below orders
node pay "payments" below products
edge users -> orders "1:N"
edge orders -> items "1:N"
edge products -> items "1:N"
edge orders -> pay "1:N"npx reladraw er-database.reladraw -o out.svgAn entity-relationship diagram that fits the most common business shape: users place orders for products, orders contain line items. Use it to lock down schema design before migration, or to document an existing database for the next developer.
node cats "categories" above products and edge cats -> products "1:N".edge orders -> pay "1:0..N" — labels are free text, so any cardinality notation works.node tags "order_tags" below items with two edges from orders and a new tags node.Each table is a node, each foreign key is an edge, and cardinality goes in the edge label (1:N, N:1). Place the central table first, then hang others around it — the template on this page is a paste-ready example.
Keep column lists out of the diagram and put PK/FK hints in labels: order_id (PK), user_id (FK). Full column lists make any diagram unreadable — link a schema file instead.
Through the join table, same as your schema: draw a node for order_items and give it two 1:N edges. That is more honest than a direct N:M edge and matches what migration code does.