Mở đầu — vì sao bài này quan trọng
Bạn từng làm Marketing, và bạn đã quen với việc nhìn dữ liệu dưới dạng "bảng": một file Excel danh sách khách hàng, một báo cáo Google Analytics với hàng cột chỉ số, một bảng UTM tracking các chiến dịch. Nhưng có một câu hỏi mà thời làm Marketing bạn hiếm khi phải trả lời: "Dữ liệu này được lưu trữ và liên kết với nhau như thế nào ở tầng hệ thống?"
Đây chính là khoảng trống lớn nhất mà một người chuyển từ Marketing sang BA cần lấp đầy. Khi bạn ngồi họp với đội Dev và họ nói "cái này phải join hai bảng customers và orders qua customer_id", nếu bạn không hiểu họ đang nói gì, bạn sẽ mất tiếng nói trong cuộc thảo luận. Tệ hơn, bạn có thể viết requirement sai vì không hình dung được dữ liệu thực sự "sống" ra sao trong cơ sở dữ liệu.
Data Modeling, mà cụ thể là ERD (Entity-Relationship Diagram — Sơ đồ thực thể quan hệ), là công cụ giúp BA bắc cây cầu giữa ngôn ngữ nghiệp vụ và ngôn ngữ kỹ thuật. ERD không yêu cầu bạn biết code, không yêu cầu bạn viết SQL. Nó chỉ yêu cầu bạn tư duy rõ ràng: hệ thống đang quản lý những "thứ" gì, mỗi "thứ" có những thông tin gì, và các "thứ" đó liên hệ với nhau ra sao.
Tin tốt cho dân Marketing: bạn vốn đã có sẵn tư duy phân loại đối tượng — bạn từng phân segment khách hàng, phân nhóm sản phẩm, gắn chiến dịch với kênh. ERD chỉ là cách hệ thống hóa lại tư duy đó một cách chính xác và có thể bàn giao cho Dev. Bài này sẽ giúp bạn đọc, hiểu và tự vẽ được một ERD ở mức BA cần.
Khái niệm cốt lõi
ERD được xây dựng từ ba thành phần nền tảng: Entity (Thực thể), Attribute (Thuộc tính) và Relationship (Mối quan hệ). Hãy đi qua từng cái một cách thật cụ thể.
Entity — Thực thể (danh từ)
Entity là một "đối tượng" mà hệ thống cần lưu thông tin về nó. Mẹo nhận diện đơn giản: Entity gần như luôn là một danh từ chỉ một loại sự vật mà bạn có thể đếm được nhiều bản ghi. Trong một hệ thống thương mại điện tử, các Entity điển hình là: Customer (Khách hàng), Order (Đơn hàng), Product (Sản phẩm), Category (Danh mục), Payment (Thanh toán).
Mỗi Entity khi triển khai thực tế thường tương ứng với một bảng (table) trong cơ sở dữ liệu. Mỗi dòng trong bảng là một instance (thể hiện) của Entity — ví dụ "khách hàng Nguyễn Văn A" là một instance của Entity Customer.
Một mẹo phân biệt quan trọng: nếu một thông tin chỉ có một giá trị duy nhất gắn với đối tượng thì nó là thuộc tính, còn nếu nó có thể tồn tại độc lập và có nhiều bản ghi riêng thì nó là Entity. Ví dụ "địa chỉ giao hàng" — nếu mỗi khách chỉ có một địa chỉ thì nó là thuộc tính của Customer; nhưng nếu một khách có thể lưu nhiều địa chỉ (nhà, công ty, nhà người yêu) thì Address nên tách thành một Entity riêng.
Attribute — Thuộc tính
Attribute là các thông tin mô tả một Entity. Entity Customer có thể có các attribute: customer_id, customer_name, email, phone, created_at. Entity Order có thể có: order_id, order_date, total_amount, status.
Có vài loại attribute đặc biệt mà BA cần nắm:
- Primary Key (Khóa chính — PK): một attribute (hoặc tổ hợp attribute) định danh duy nhất mỗi bản ghi. Ví dụ
customer_idlà PK củaCustomer— không có hai khách trùngcustomer_id. Đây là "số chứng minh thư" của mỗi bản ghi. - Foreign Key (Khóa ngoại — FK): một attribute trong bảng này trỏ tới PK của bảng khác, dùng để tạo mối quan hệ. Ví dụ trong bảng
Ordercó attributecustomer_id— đó là FK trỏ về bảngCustomer, cho biết đơn hàng này thuộc về khách nào.
Relationship — Mối quan hệ
Đây là phần mà ý định gốc của bài bỏ ngỏ, và cũng là phần quan trọng nhất. Relationship mô tả cách các Entity liên kết với nhau. Có ba loại cardinality (lượng số) chính:
- One-to-One (1:1): Mỗi bản ghi của Entity A ứng với đúng một bản ghi của Entity B. Ví dụ: mỗi
Customercó đúng mộtLoyaltyAccount(tài khoản tích điểm). - One-to-Many (1:N): Một bản ghi của A ứng với nhiều bản ghi của B, nhưng mỗi B chỉ thuộc về một A. Đây là loại phổ biến nhất. Ví dụ: một
Customercó nhiềuOrder, nhưng mỗiOrderchỉ thuộc về mộtCustomer. - Many-to-Many (M:N): Nhiều A ứng với nhiều B. Ví dụ: một
Orderchứa nhiềuProduct, và mộtProductxuất hiện trong nhiềuOrder. Quan hệ M:N không lưu trực tiếp được; phải tách ra một bảng trung gian (junction table / associative entity), ví dụOrder_Item, chứaorder_idvàproduct_id.
Order bắt buộc phải có một Customer (không có đơn hàng vô chủ), nhưng một Customer có thể tồn tại mà chưa có Order nào (khách mới đăng ký, chưa mua). Modality này được biểu diễn bằng ký hiệu "vòng tròn" (0 — tùy chọn) và "gạch" (1 — bắt buộc) trong ký pháp Crow's Foot — ký pháp "chân quạ" phổ biến nhất hiện nay, với biểu tượng ba chạc giống chân chim để chỉ "nhiều".Tình huống thực tế
Tình huống 1 — Tiki và quan hệ M:N giữa đơn hàng và sản phẩm
Hãy hình dung bạn là BA mới tại một sàn TMĐT kiểu Tiki. PM yêu cầu: "Khách phải xem được lịch sử mua hàng, mỗi đơn liệt kê các sản phẩm đã mua kèm số lượng và giá tại thời điểm mua."
Một BA non kinh nghiệm sẽ vẽ thẳng quan hệ Order — Product. Nhưng đây là quan hệ M:N: một đơn chứa nhiều sản phẩm, một sản phẩm nằm trong nhiều đơn. Bạn không thể nhồi danh sách sản phẩm vào một ô của bảng Order. Giải pháp chuẩn là tạo bảng trung gian Order_Item với các attribute: order_id (FK), product_id (FK), quantity, unit_price_at_purchase.
Chi tiết tinh tế: tại sao phải lưu unit_price_at_purchase thay vì lấy giá từ bảng Product? Vì giá sản phẩm thay đổi theo thời gian. Nếu một chiếc tai nghe giá 500.000đ hôm nay nhưng tháng sau giảm còn 400.000đ, hóa đơn cũ của khách vẫn phải hiển thị 500.000đ. Nếu bạn quên attribute này, hệ thống sẽ hiển thị sai lịch sử và đội kế toán sẽ "khóc thét".
Bài học rút ra: Quan hệ M:N luôn cần bảng trung gian, và bảng trung gian thường mang theo các attribute riêng (quantity, price tại thời điểm giao dịch). Tư duy "chụp ảnh giá tại thời điểm mua" là điều BA giỏi phải nghĩ tới ngay từ bước data modeling, không đợi Dev nhắc.
Tình huống 2 — MoMo và Entity ẩn trong nghiệp vụ ví điện tử
Một fintech kiểu MoMo cần mô hình hóa giao dịch chuyển tiền. PM mô tả nghiệp vụ rất "đời": "User A chuyển tiền cho User B." Một BA từ nền Marketing dễ vẽ thành quan hệ giữa hai Entity User, với một bảng Transaction có sender_id và receiver_id.
Điều đó đúng, nhưng chưa đủ. Khi đào sâu, bạn phát hiện mỗi giao dịch còn liên quan tới số dư ví và phải đảm bảo tính nhất quán kế toán. Ở đây xuất hiện một Entity ẩn: Wallet (Ví). Mỗi User có một Wallet (quan hệ 1:1), và Transaction thực chất tác động lên Wallet chứ không phải trực tiếp lên User. Mô hình chuẩn trở thành: User (1:1) Wallet, và Transaction có from_wallet_id và to_wallet_id (cùng trỏ về Wallet).
Vì sao điều này quan trọng với bối cảnh Việt Nam? Vì một user có thể có ví VND và ví điểm thưởng riêng — lúc này quan hệ User–Wallet chuyển thành 1:N, và mô hình ban đầu của bạn sẽ sụp đổ nếu bạn gắn chặt giao dịch vào User.
Bài học rút ra: Đừng dừng ở những danh từ mà stakeholder nói ra. Hãy đào tìm các Entity ẩn đứng sau nghiệp vụ. Câu hỏi vàng để phát hiện Entity ẩn là: "Thông tin này thực sự gắn vào đối tượng nào, và đối tượng đó có thể nhân lên nhiều bản ghi không?"
Tình huống 3 — Edtech Việt và self-referencing relationship
Một startup edtech (kiểu một nền tảng học trực tuyến nội địa) cần mô hình hóa cấu trúc khóa học có danh mục phân cấp: "Lập trình" chứa "Web", "Web" chứa "Frontend"... không giới hạn số tầng. Marketing background của bạn quen với cấu trúc phẳng (category là một cột trong file sản phẩm), nên bạn dễ bí.
Lời giải là self-referencing relationship (quan hệ tự tham chiếu). Entity Category có một FK parent_category_id trỏ về chính bảng Category. Danh mục gốc thì parent_category_id để trống (NULL). Đây là một mô hình kinh điển cho mọi cấu trúc cây: danh mục sản phẩm, sơ đồ tổ chức nhân sự (nhân viên báo cáo cho quản lý cũng là nhân viên), bình luận có reply lồng nhau.
Bài học rút ra: Một Entity hoàn toàn có thể quan hệ với chính nó. Khi nghiệp vụ có yếu tố "phân cấp", "lồng nhau", "báo cáo cho", hãy nghĩ ngay tới self-referencing FK thay vì tạo ra hàng loạt bảng Category_Level_1, Category_Level_2 — một anti-pattern khiến hệ thống cứng nhắc.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để dựng một ERD từ một mô tả nghiệp vụ:
Bước 1 — Gạch chân danh từ. Đọc kỹ mô tả requirement, gạch chân mọi danh từ. "Khách hàng đặt đơn hàng gồm nhiều sản phẩm, thanh toán qua một phương thức." → Khách hàng, đơn hàng, sản phẩm, phương thức thanh toán. Đây là các ứng viên Entity.
Bước 2 — Lọc Entity thật. Không phải danh từ nào cũng thành Entity. Loại bỏ những danh từ chỉ là thuộc tính (ví dụ "tên", "ngày") hoặc trùng nghĩa. Giữ lại các đối tượng có thể nhân thành nhiều bản ghi và cần lưu trữ độc lập.
Bước 3 — Liệt kê attribute cho mỗi Entity. Với từng Entity, hỏi: "Hệ thống cần biết những gì về nó?" Xác định ngay attribute nào làm Primary Key.
Bước 4 — Xác định relationship và cardinality. Với từng cặp Entity, hỏi hai câu: "Một A có thể gắn với mấy B?" và ngược lại "Một B gắn với mấy A?" Câu trả lời cho bạn 1:1, 1:N hay M:N. Đừng quên hỏi tính bắt buộc (modality).
Bước 5 — Xử lý quan hệ M:N. Mọi quan hệ M:N phải tách thành bảng trung gian. Đặt tên rõ nghĩa (Order_Item, Enrollment, Student_Course) và xem nó có cần attribute riêng không.
Bước 6 — Vẽ và rà soát cùng Dev. Dùng công cụ như draw.io (diagrams.net), Lucidchart, dbdiagram.io hoặc Miro để vẽ bằng ký pháp Crow's Foot. Sau đó ngồi rà cùng một Dev/DBA — họ sẽ phát hiện những vấn đề chuẩn hóa dữ liệu mà bạn chưa thấy. ERD là tài liệu để thảo luận, không phải để khoe.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi nhiều giá trị vào một ô. Dân Marketing quen Excel nên hay viết requirement kiểu "cột tags chứa danh sách thẻ phân cách bằng dấu phẩy". Trong database, đây là vi phạm chuẩn hóa. Nếu một đối tượng có nhiều giá trị của cùng một loại, đó là dấu hiệu của một quan hệ 1:N hoặc M:N cần bảng riêng.
Lỗi 2 — Quên modality. Chỉ ghi cardinality mà quên hỏi "có bắt buộc không". Việc một Order bắt buộc có Customer hay không ảnh hưởng trực tiếp tới việc Dev có cho phép NULL ở FK hay không — và đó là quyết định nghiệp vụ, không phải kỹ thuật.
Lỗi 3 — Lẫn lộn Entity với báo cáo. "Báo cáo doanh thu tháng" không phải Entity — nó là kết quả truy vấn tổng hợp từ các Entity Order, Order_Item. Đừng tạo bảng cho thứ có thể tính ra được.
Lỗi 4 — Vẽ quá chi tiết quá sớm. Ở giai đoạn đầu (conceptual model), chỉ cần Entity và relationship, chưa cần liệt kê hết attribute. Vẽ quá chi tiết khiến sơ đồ rối và khó thảo luận với stakeholder nghiệp vụ.
Mẹo: Học ba mức của data model — Conceptual (chỉ Entity + quan hệ, dùng để nói chuyện với business), Logical (thêm attribute, PK, FK, chưa gắn database cụ thể), Physical (kiểu dữ liệu, index — việc của Dev/DBA). BA chủ yếu sống ở tầng Conceptual và Logical. Biết ranh giới này giúp bạn biết khi nào nên dừng và bàn giao.
Mẹo: Khi đặt tên, dùng số ít cho tên Entity (Customer chứ không Customers) và đặt tên nhất quán (snake_case hoặc camelCase, chọn một). Sự nhất quán nhỏ này tiết kiệm rất nhiều tranh cãi sau này.
Bài tập thực hành
Hãy thực hành với một tình huống sát thực tế Việt Nam: Bạn là BA cho một ứng dụng đặt lịch spa/salon (kiểu một nền tảng booking làm đẹp).
Mô tả nghiệp vụ: "Khách hàng đặt lịch hẹn tại một chi nhánh, chọn một hoặc nhiều dịch vụ, do một nhân viên kỹ thuật phục vụ. Mỗi dịch vụ có giá và thời lượng. Khách có thể đánh giá sao sau khi dùng dịch vụ."
Yêu cầu của bạn:
- Liệt kê tất cả Entity bạn nhận diện được (gợi ý: có ít nhất 5).
- Với mỗi Entity, ghi 3–5 attribute và chỉ ra Primary Key.
- Xác định cardinality và modality cho các cặp quan hệ chính.
- Chỉ ra ít nhất một quan hệ M:N và đặt tên cho bảng trung gian của nó.
- Vẽ ERD bằng draw.io hoặc dbdiagram.io theo ký pháp Crow's Foot.
Appointment (Lịch hẹn) và Service (Dịch vụ) là M:N — bạn cần một bảng trung gian. Quan hệ giữa Branch (Chi nhánh) và Appointment là 1:N. Hãy tự hỏi: "Đánh giá sao" gắn vào lịch hẹn hay gắn vào dịch vụ? Câu trả lời sẽ quyết định bạn đặt FK ở đâu.Tóm tắt
ERD là công cụ giúp BA biến mô tả nghiệp vụ mơ hồ thành một bức tranh dữ liệu rõ ràng mà Dev có thể triển khai. Ba thành phần cốt lõi cần nằm lòng: Entity (danh từ, mỗi cái thường thành một bảng), Attribute (thông tin mô tả, đặc biệt là Primary Key và Foreign Key), và Relationship (1:1, 1:N, M:N kèm tính bắt buộc).
Những điểm then chốt: mọi quan hệ M:N phải tách thành bảng trung gian; hãy đào tìm Entity ẩn đứng sau lời nói của stakeholder; cảnh giác với thói quen "nhồi Excel" từ thời Marketing; và biết dừng đúng tầng (Conceptual/Logical là sân chơi của BA). Với nền tảng tư duy phân loại sẵn có từ Marketing, bạn hoàn toàn đủ sức làm chủ kỹ năng này — chỉ cần luyện đọc và vẽ ERD đều đặn qua các nghiệp vụ thật. Ở các bài sau, kỹ năng này sẽ là nền để bạn bóc tách business rules và đặc tả use case một cách chính xác.