Mở đầu — vì sao bài này quan trọng
Sau mười lăm bài học, bạn đã có trong tay toàn bộ lý thuyết để dựng một mô hình dữ liệu tử tế: bạn biết phân biệt entity với attribute, biết chọn primary key, biết vẽ quan hệ và đọc ký hiệu cardinality, biết chuẩn hóa tới 3NF rồi cân nhắc denormalize khi cần. Nhưng có một sự thật phũ phàng mà nhiều bạn BA gặp phải: lý thuyết tốt mà công cụ vẽ kém thì sản phẩm vẫn xấu, chậm và khó bảo trì.
Tôi đã chứng kiến không ít BA giỏi nghiệp vụ nhưng dành ba tiếng đồng hồ vật lộn với PowerPoint để vẽ một ERD mười bảng — kéo từng mũi tên, căn từng ô chữ nhật, rồi khi khách hàng yêu cầu thêm một bảng ở giữa, toàn bộ sơ đồ vỡ vụn phải làm lại. Trong khi đó, một người chọn đúng công cụ chỉ mất hai mươi phút, và khi cần đổi thì sửa trong vài cú click.
Bài này không phải về lý thuyết data modeling nữa — nó về năng suất và sự cộng tác. Chọn đúng công cụ ERD giúp bạn vẽ nhanh hơn, chia sẻ dễ hơn với đội dev, đồng bộ với tài liệu nghiệp vụ, và quan trọng nhất: biến mô hình trong đầu bạn thành thứ mà cả team nhìn vào là hiểu. Chúng ta sẽ đi sâu vào ba công cụ phổ biến nhất trong thực tế thị trường Việt Nam và khu vực — draw.io (diagrams.net), Lucidchart, và dbdiagram.io — để bạn biết khi nào dùng cái nào.
Khái niệm cốt lõi
Trước khi so sánh từng công cụ, cần hiểu rằng các công cụ ERD chia làm hai trường phái lớn, và việc bạn thuộc trường phái nào quyết định công cụ phù hợp.
Hai trường phái: vẽ tay (visual) vs. viết code (diagram-as-code)
Trường phái visual là kéo-thả truyền thống: bạn dùng chuột tạo hộp, nối đường, gõ chữ trực tiếp lên canvas. Ưu điểm là trực quan, ai cũng làm được ngay, phù hợp khi trình bày cho người không chuyên (khách hàng, sếp). Nhược điểm là chậm khi mô hình lớn và khó quản lý phiên bản (version control). draw.io và Lucidchart thuộc trường phái này.
Trường phái diagram-as-code là bạn viết mô tả bảng bằng cú pháp văn bản, công cụ tự render thành sơ đồ. Ưu điểm là cực nhanh khi đã quen, dễ lưu trong Git, dễ copy-paste giữa các dự án, và sơ đồ luôn được sắp xếp gọn gàng tự động. Nhược điểm là cần học cú pháp và khó đẹp mắt khi trình bày cho người ngoài kỹ thuật. dbdiagram.io thuộc trường phái này (Mermaid cũng vậy, nhưng ta để dành cho Bài 43).
Tiêu chí đánh giá một công cụ ERD
Khi đánh giá, tôi luôn nhìn vào sáu tiêu chí:
- Chi phí — miễn phí hay trả phí, có giới hạn gì ở bản free.
- Hỗ trợ Crow's Foot notation — đây là ký hiệu chuẩn công nghiệp mà bạn đã học ở Bài 8; công cụ nào không hỗ trợ sẵn thì rất phiền.
- Cộng tác thời gian thực — nhiều người cùng sửa một lúc, comment, gán việc.
- Tích hợp — kết nối được với Confluence, Jira, Google Workspace, hay xuất ra SQL DDL không.
- Khả năng reverse engineering — đọc một database có sẵn rồi tự sinh ERD (rất quý khi review schema cũ — bạn sẽ làm việc này ở Bài 35).
- Đường cong học tập — bao lâu để một thành viên mới dùng được.
draw.io / diagrams.net — lựa chọn miễn phí "quốc dân"
draw.io (tên mới là diagrams.net) là công cụ miễn phí, mã nguồn mở, chạy được cả online tại app.diagrams.net lẫn cài desktop offline cho macOS/Windows/Linux. Nó có sẵn thư viện Entity Relation với ký hiệu Crow's Foot, hỗ trợ tích hợp sâu vào Confluence và Google Drive — đây là lý do nhiều công ty outsourcing Việt Nam dùng Confluence chọn ngay draw.io. Điểm mạnh lớn nhất: dữ liệu của bạn có thể lưu thẳng vào Google Drive hoặc file .drawio trong repo, không bị khóa vào một nhà cung cấp nào.
Lucidchart — bản trả phí mạnh về cộng tác
Lucidchart là công cụ thương mại, trả phí, mạnh nhất ở khía cạnh cộng tác doanh nghiệp: nhiều người sửa cùng lúc mượt mà, comment theo luồng, tích hợp chính thức với Confluence/Jira/Google/Microsoft, và đặc biệt có tính năng import database để tự sinh ERD (reverse engineering) ở các gói cao. Bản miễn phí giới hạn 3 sơ đồ và 60 object mỗi sơ đồ — đủ để thử nhưng không đủ cho dự án thật.
dbdiagram.io — diagram-as-code cho người yêu tốc độ
dbdiagram.io dùng một ngôn ngữ riêng tên DBML (Database Markup Language). Bạn gõ định nghĩa bảng, nó render ERD ngay. Cực nhanh, và quan trọng là xuất được SQL DDL cho PostgreSQL, MySQL, SQL Server — tức là từ sơ đồ ra thẳng câu lệnh tạo bảng. Đây là cầu nối tuyệt vời giữa mô hình logic và physical mà bạn sẽ thấy rõ ở các bài physical model.
Tình huống thực tế
Tình huống 1 — Công ty fintech "MoMoclone" và cuộc họp khách hàng
Một startup ví điện tử tại TP.HCM (gọi là MViPay) cần trình bày mô hình dữ liệu hệ thống nạp/rút tiền cho nhà đầu tư Nhật Bản. Chị BA trưởng nhóm ban đầu định dùng dbdiagram.io vì nó nhanh, nhưng khi đưa lên màn hình họp, các nhà đầu tư phi kỹ thuật nhìn vào khối DBML và sơ đồ dày đặc tỏ ra bối rối — họ muốn thấy "bức tranh nghiệp vụ" có màu sắc, nhóm khối, chú thích tiếng Việt lẫn tiếng Anh.
Chị chuyển sang Lucidchart, dùng tính năng nhóm màu (container) để khoanh vùng "Cụm Tài khoản", "Cụm Giao dịch", "Cụm Đối soát", thêm chú thích và icon. Buổi họp diễn ra trôi chảy, nhà đầu tư gật gù. Bài học rút ra: công cụ phải chọn theo khán giả. Với người ra quyết định phi kỹ thuật, tính trực quan và trình bày đẹp quan trọng hơn tốc độ vẽ.
Tình huống 2 — Team outsourcing 8 người và ngân sách bằng 0
Một công ty gia công phần mềm ở Đà Nẵng nhận dự án quản lý kho cho khách Singapore, đội 8 người gồm 2 BA và 6 dev, dùng Confluence làm wiki nội bộ. Sếp không duyệt mua license Lucidchart vì "dự án nhỏ, biên lợi nhuận mỏng". Họ chọn draw.io vì miễn phí và cắm thẳng plugin vào Confluence: BA vẽ ERD ngay trong trang wiki mô tả nghiệp vụ kho, dev mở cùng trang đó đọc và comment.
Khi khách yêu cầu thêm bảng lot (lô hàng) để quản lý hạn sử dụng, BA chỉ cần mở sơ đồ .drawio đính kèm, thêm bảng, nối quan hệ một-nhiều với product, lưu lại — Confluence tự cập nhật ảnh nhúng. Bài học rút ra: khi ngân sách bằng 0 và đã có Confluence, draw.io gần như là lựa chọn mặc định không cần bàn cãi. Việc lưu file .drawio ngay trong wiki cũng giúp tài liệu và sơ đồ không bị lệch nhau.
Tình huống 3 — BA kiêm "nửa dev" và quy trình Git
Tại một công ty sản phẩm (product company) ở Hà Nội làm nền tảng đặt lịch khám bệnh, anh BA có nền tảng kỹ thuật làm việc rất gần với team backend theo quy trình code review trên GitLab. Anh muốn ERD được quản lý phiên bản như code — mỗi lần đổi schema là một commit, có diff rõ ràng, review được.
Anh chọn dbdiagram.io và lưu file DBML vào repo. Khi cần thêm trường insurance_code vào bảng patient, anh sửa một dòng DBML, tạo merge request, dev review thấy ngay "à, thêm mã bảo hiểm y tế". Sau đó anh dùng nút export của dbdiagram để sinh SQL DDL cho PostgreSQL, dán vào file migration. Bài học rút ra: với team coi schema là code và dùng Git nghiêm túc, diagram-as-code thắng tuyệt đối — vì nó cho bạn lịch sử thay đổi, diff, và xuất thẳng ra DDL, giảm sai sót sao chép thủ công.
Hướng dẫn từng bước
Tôi sẽ hướng dẫn bạn vẽ một ERD đơn giản (3 bảng: customer, order, order_item) trên cả hai trường phái để bạn cảm nhận khác biệt.
Cách 1 — Vẽ bằng draw.io (visual):
- Mở app.diagrams.net, chọn lưu vào Google Drive hoặc Device.
- Tạo Blank Diagram. Ở thanh tìm shape bên trái, gõ "table" và chọn shape Entity 2 (loại có header tên bảng và các dòng thuộc tính).
- Kéo 3 bảng ra canvas. Đặt tên
customer,order,order_item. Trong mỗi bảng, click vào dòng để sửa thành các thuộc tính, ví dụcustomer:customer_id (PK),full_name,phone. - Bật notation Crow's Foot: ở thanh tìm gõ "crow", lấy các đường nối có ký hiệu chân quạ. Nối
customertớiorder(một khách – nhiều đơn),ordertớiorder_item(một đơn – nhiều dòng). - Chọn đầu mút đường nối, trong panel Style đặt đúng ký hiệu: đầu "một" là vạch, đầu "nhiều" là chân quạ.
- File → Export as → PNG/PDF, hoặc nếu dùng Confluence thì nhúng trực tiếp.
- Mở dbdiagram.io, vào Editor.
- Gõ định nghĩa bằng DBML:
Table customer {
customer_id int [pk]
full_name varchar
phone varchar
}Table "order" {
order_id int [pk]
customer_id int [ref: > customer.customer_id]
order_date datetime
}
Table order_item {
order_item_id int [pk]
order_id int [ref: > "order".order_id]
product_id int
quantity int
}
- Sơ đồ tự render bên phải, quan hệ một-nhiều tự vẽ nhờ cú pháp
ref: >. - Bấm Export → PostgreSQL để lấy SQL CREATE TABLE, hoặc Export PNG/PDF để chèn vào tài liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn công cụ trước khi hiểu nhu cầu. Nhiều bạn mặc định "công ty mua Lucidchart thì dùng Lucidchart cho mọi thứ". Sai. Nếu bạn cần xuất DDL nhanh và quản lý theo Git, dbdiagram tốt hơn dù miễn phí. Hãy hỏi: Khán giả là ai? Có cần version control không? Có cần xuất SQL không?
Lỗi 2 — Vẽ ERD đẹp nhưng không nhất quán với tài liệu nghiệp vụ. Sơ đồ một nơi, mô tả entity một nẻo, sau ba tháng không ai biết cái nào đúng. Mẹo: với draw.io hãy nhúng .drawio thẳng vào Confluence; với dbdiagram hãy để file DBML trong repo cạnh code. Để sơ đồ "sống" cùng nguồn dữ liệu, đừng để nó thành ảnh chụp chết.
Lỗi 3 — Không dùng Crow's Foot mà tự bịa ký hiệu. Tôi từng thấy ERD vẽ quan hệ bằng mũi tên một chiều như flowchart, khiến dev không biết bên nào "một" bên nào "nhiều". Luôn dùng notation chuẩn mà công cụ hỗ trợ sẵn (Bài 8 đã dạy đọc).
Lỗi 4 — Quên giới hạn bản free. Lucidchart free chỉ 3 sơ đồ, 60 object. Bạn vẽ hăng say đến object thứ 61 thì bị chặn, mất công. Biết trước giới hạn để quyết định sớm.
Mẹo vàng: Nhiều team chuyên nghiệp dùng kết hợp — dùng dbdiagram để dựng nhanh và xuất DDL, rồi chụp/nhập sang Lucidchart hoặc draw.io để "làm đẹp" khi cần trình bày cho khách. Đừng nghĩ phải trung thành với một công cụ duy nhất.
Mẹo cho dữ liệu nhạy cảm: Nếu mô hình chứa thông tin nhạy cảm (ví dụ schema lõi của ngân hàng), cân nhắc dùng draw.io bản desktop offline để dữ liệu không rời máy bạn — điều mà công cụ chỉ-online như Lucidchart hay dbdiagram khó đảm bảo.
Bài tập thực hành
- Vẽ song song: Lấy mô hình 3 bảng
customer–order–order_itemở phần hướng dẫn, vẽ nó trên cả draw.io và dbdiagram.io. Bấm giờ xem mỗi cách mất bao lâu, và ghi lại cảm nhận về độ thoải mái của bạn với từng trường phái.
- Bảng so sánh: Tự lập bảng so sánh draw.io, Lucidchart, dbdiagram theo 6 tiêu chí (chi phí, Crow's Foot, cộng tác, tích hợp, reverse engineering, đường cong học tập). Điền mỗi ô một câu ngắn. Đây sẽ là "cheat sheet" cá nhân để bạn chọn công cụ cho dự án sau.
- Tình huống ra quyết định: Cho ba bối cảnh sau, bạn chọn công cụ nào và vì sao (viết 2–3 câu mỗi câu trả lời):
- Xuất DDL: Trên dbdiagram.io, thêm vào mô hình một bảng
paymentliên kết một-một vớiorder, rồi xuất SQL DDL cho MySQL. Đọc kỹ câu lệnh sinh ra: nó tạo khóa ngoại như thế nào?
Tóm tắt
Công cụ không thay thế tư duy mô hình hóa, nhưng đúng công cụ giúp tư duy đó biến thành sản phẩm nhanh và sạch. Hãy nhớ ba điều cốt lõi: (1) draw.io là lựa chọn miễn phí, mã nguồn mở, mạnh khi đã có Confluence/Google và cần bản offline cho dữ liệu nhạy cảm; (2) Lucidchart trả phí nhưng vượt trội về cộng tác doanh nghiệp, trình bày đẹp và reverse engineering, hợp khi khán giả là người ra quyết định; (3) dbdiagram.io theo trường phái diagram-as-code, nhanh như chớp, quản lý được bằng Git và xuất thẳng SQL DDL, lý tưởng cho team coi schema là code.
Quy tắc chọn của tôi gói gọn trong ba câu hỏi: Khán giả là ai? Có cần version control không? Có cần xuất SQL không? Trả lời được ba câu này, bạn sẽ không bao giờ chọn nhầm công cụ. Và đừng quên: các công cụ này không loại trừ nhau — người làm dữ liệu giỏi biết phối hợp chúng. Ở Bài 43, chúng ta sẽ đào sâu hơn vào trường phái ERD-as-code với Mermaid; còn bây giờ, hãy mở một công cụ lên và bắt tay vẽ — vì kỹ năng này chỉ giỏi lên khi bạn thực hành.