Trình thiết kế ERD

Thiết kế schema quan hệ mà không cần máy chủ cơ sở dữ liệu: thêm bảng, gắn cho chúng các cột có kiểu, khóa và giá trị mặc định, rồi nối chúng bằng các quan hệ. Sơ đồ thực thể-quan hệ vẽ lại khi bạn gõ, và cùng mô hình đó xuất được thành DDL CREATE TABLE cho MySQL, PostgreSQL, SQL Server, SQLite hoặc Oracle, thành mã nguồn Mermaid erDiagram, hoặc thành JSON schema di động mà bạn có thể nhập lại ở đây hoặc mở trong Bộ tạo migration. Mọi thứ chạy cục bộ.
ERD là gì? ERD là viết tắt của sơ đồ thực thể-quan hệ, và đó là bản vẽ thiết kế của một cơ sở dữ liệu chứ không phải bản ghi của một cái đã hoàn thành. Một so sánh hữu ích là bản vẽ thiết kế của một tòa nhà: cơ sở dữ liệu đang chạy là tòa nhà, ERD là bản vẽ, và không ai đổ bê tông trước rồi đo sau. Trang này là bàn vẽ cho bản thiết kế đó — bạn tạo hình mô hình ở đây, và DDL, mã Mermaid và JSON schema đều được in ra từ cùng một mô hình, nên hình vẽ không thể lệch khỏi SQL mà nó đã tạo ra.
Cùng một sơ đồ ở ba cấp độ. Một ERD khái niệm chỉ nêu những thứ quan trọng và cách chúng liên hệ, bằng ngôn ngữ mà người không lập trình có thể kiểm tra. Một ERD logic thêm các khóa xác định từng thứ và giải quyết các liên kết nhiều-nhiều, trong khi không dính đến phương ngữ của bất kỳ engine nào. Một ERD vật lý điền vào những gì một sản phẩm cụ thể đòi hỏi — độ rộng kiểu, giá trị mặc định, khả năng null, ràng buộc duy nhất, quy tắc xóa — và đó là cấp độ bạn xuất ở đây khi chọn MySQL, PostgreSQL, SQL Server, SQLite hoặc Oracle.
Các hộp đến từ đâu. Đọc mô tả hệ thống và gạch chân các danh từ: khách hàng, hóa đơn, sản phẩm, lô hàng. Đó là các bảng. Các sự kiện và thuộc tính gắn với một danh từ — ngày hóa đơn, đơn giá, địa chỉ email — là các cột của nó. Một động từ nối hai danh từ, như trong “một đơn hàng được đặt bởi một khách hàng”, là một quan hệ, và nó được lưu bằng cách sao chép khóa xác định của hàng cha vào hàng con dưới dạng khóa ngoại.
Khi một liên kết là nhiều-nhiều. Một công thức dùng nhiều nguyên liệu và một nguyên liệu xuất hiện trong nhiều công thức, nên không bảng nào có thể giữ khóa của bảng kia mà không lặp lại chính nó. Lời giải là một thực thể thứ ba với nhiệm vụ duy nhất là ghép cặp chúng — bảng nối (hoặc bảng liên kết), giữ một khóa ngoại cho mỗi phía, thường với cặp khóa đó làm khóa chính của chính nó. Một mô hình phần lớn là các bảng ghép cặp như vậy là hoàn toàn bình thường: một đường nhiều-nhiều trên bảng trắng luôn phải trở thành một hộp trong schema thật.
Vì sao cần làm trước khi có DDL. Một đường sai trên bản vẽ tốn một phút để xóa; cùng lỗi phát hiện sau khi phát hành tốn một migration trên dữ liệu đang chạy. Sơ đồ cũng là hiện vật duy nhất mà người không phải lập trình viên có thể duyệt, và các lỗi quan hệ — bậc quan hệ ngược chiều, thiếu khóa duy nhất, hàng con có thể bị bỏ lại không có cha — hiện ra thành những đường rõ ràng là sai ở đây, trong khi trong một tệp DDL 400 dòng chúng ẩn giữa các ràng buộc.
Xuôi hay ngược? Trình thiết kế này đi xuôi: mô hình trước, DDL ra sau. Trang anh em SQL sang ERD đi theo chiều ngược lại — dán các câu lệnh CREATE TABLE có sẵn và nó dựng lại sơ đồ, đây là con đường nhanh hơn khi cơ sở dữ liệu đã tồn tại.
1 — Bảng
Sửa Tên bảng Các cột Quan hệ Actions
2 — Cột
Cột Loại PK AI NN UQ Mặc định Actions
PK = khóa chính, AI = tự tăng / identity, NN = không null, UQ = duy nhất
3 — Quan hệ (khóa ngoại)
Bảng con Cột con Actions Bảng cha Cột cha Khi xóa Actions
Khóa ngoại trở thành một dòng CONSTRAINT ... FOREIGN KEY trong DDL.
4 — Xuất
Mã nguồn Mermaid erDiagram
Mô hình JSON là định dạng trao đổi của bộ công cụ cơ sở dữ liệu: dán nó vào Bộ tạo migration như schema trước/sau, hoặc nhập lại ở đây để tiếp tục sửa sau này.