Mở đầu — vì sao bài này quan trọng
Là một Business Analyst, bạn có thể nghĩ rằng database (cơ sở dữ liệu) là việc của developer hay DBA (Database Administrator), còn bạn chỉ cần quan tâm tới requirement và quy trình nghiệp vụ. Nhưng thực tế hành nghề lại kể một câu chuyện khác.
Hãy hình dung tình huống này: bạn ngồi họp với team kỹ thuật để thiết kế tính năng "khách hàng có thể có nhiều địa chỉ giao hàng". Dev hỏi: "Một khách hàng tối đa bao nhiêu địa chỉ? Khi xóa khách hàng thì địa chỉ xử lý sao? Địa chỉ có cần lưu lịch sử thay đổi không?". Nếu bạn không hiểu cách dữ liệu được tổ chức bên dưới, bạn sẽ không trả lời được, và requirement của bạn sẽ bị trả về liên tục để làm rõ.
Database chính là nơi nghiệp vụ của doanh nghiệp được "đóng băng" thành dữ liệu thật. Mọi đơn hàng, mọi khách hàng, mọi giao dịch mà bạn mô tả trong tài liệu nghiệp vụ cuối cùng đều nằm trong các bảng dữ liệu. Khi bạn hiểu cấu trúc này, bạn viết requirement chính xác hơn, đặt câu hỏi đúng hơn, và quan trọng nhất — bạn nói cùng ngôn ngữ với đội kỹ thuật.
Bài này không biến bạn thành kỹ sư database. Mục tiêu là giúp bạn nắm vững các khái niệm nền tảng của database quan hệ (relational database): bảng, khóa, mối quan hệ, và đặc biệt là cách đọc và vẽ ERD — công cụ giao tiếp số một giữa BA và team dữ liệu. Đây là phần kiến thức nền giúp bạn tự tin ngồi vào bàn thiết kế.
Khái niệm cốt lõi
Relational Database là gì
Relational database (cơ sở dữ liệu quan hệ) là loại database phổ biến nhất trong thế giới doanh nghiệp. Tên gọi "quan hệ" đến từ việc dữ liệu được tổ chức thành các bảng có liên kết với nhau. Những hệ quản trị bạn sẽ nghe nhắc đến thường xuyên là MySQL, PostgreSQL, SQL Server (Microsoft) và Oracle.
Đơn vị cơ bản là table (bảng). Mỗi bảng lưu một loại thực thể nghiệp vụ. Ví dụ bảng Customers lưu khách hàng, bảng Orders lưu đơn hàng. Một bảng gồm:
- Column (cột): mỗi cột là một thuộc tính. Bảng
Customerscó thể có các cộtcustomer_id,full_name,email,phone,created_at. Mỗi cột có một kiểu dữ liệu (data type) cố định: số nguyên, chuỗi văn bản, ngày tháng, true/false... - Row (hàng / record / bản ghi): mỗi hàng là một bản ghi cụ thể. Một hàng trong
Customersđại diện cho một khách hàng thật, ví dụ "Nguyễn Văn An, an@gmail.com, 0901234567".
Primary Key và Foreign Key — trái tim của "quan hệ"
Đây là hai khái niệm bạn bắt buộc phải nắm vững vì chúng quyết định cách các bảng nối với nhau.
Primary Key (PK — khóa chính) là một cột (hoặc nhóm cột) định danh duy nhất từng hàng trong bảng. Trong bảng Customers, customer_id là primary key: không có hai khách hàng nào trùng customer_id. Nhờ đó, dù có hai khách hàng cùng tên "Nguyễn Văn An", hệ thống vẫn phân biệt được họ qua mã định danh. Khóa chính không bao giờ rỗng (NULL) và không trùng lặp.
Foreign Key (FK — khóa ngoại) là cột trong bảng này trỏ tới primary key của bảng khác. Đây chính là sợi dây nối các bảng. Ví dụ bảng Orders có cột customer_id là foreign key trỏ về Customers.customer_id. Khi nhìn vào một đơn hàng, bạn biết ngay nó thuộc về khách hàng nào.
Hãy minh họa bằng dữ liệu cụ thể:
Bảng Customers:
| customer_id (PK) | full_name | |
|---|---|---|
| 1 | Nguyễn Văn An | an@gmail.com |
| 2 | Trần Thị Bích | bich@gmail.com |
Orders:| order_id (PK) | customer_id (FK) | total_amount | order_date |
|---|---|---|---|
| 1001 | 1 | 350000 | 2026-06-01 |
| 1002 | 1 | 120000 | 2026-06-15 |
| 1003 | 2 | 890000 | 2026-06-20 |
SQL — ngôn ngữ để hỏi dữ liệu
SQL (Structured Query Language) là ngôn ngữ chuẩn để truy vấn và thao tác dữ liệu trong relational database. Là BA, bạn không cần viết SQL phức tạp, nhưng đọc hiểu được câu lệnh cơ bản giúp bạn tự kiểm chứng dữ liệu thay vì lúc nào cũng phải nhờ dev.
Một câu truy vấn đọc dữ liệu cơ bản:
SELECT full_name, email
FROM Customers
WHERE created_at >= '2026-01-01';
Đọc nôm na: "Lấy tên và email từ bảng Customers, với điều kiện khách hàng được tạo từ đầu năm 2026". Bạn chỉ cần nắm bốn từ khóa: SELECT (chọn cột nào), FROM (từ bảng nào), WHERE (điều kiện lọc), và JOIN (nối hai bảng qua khóa). Bốn từ này đủ để bạn đọc hiểu phần lớn các truy vấn nghiệp vụ thường gặp.
Lưu ý quan trọng về phạm vi bài này: chúng ta dừng ở mức khái niệm. Việc so sánh SQL với NoSQL, chọn loại database nào, các kiểu quan hệ chi tiết, hay từng loại database cụ thể như MongoDB, Redis sẽ được học sâu ở các bài sau. Ở đây mục tiêu là bạn hiểu được "khung xương" của một relational database.
ERD — bản đồ dữ liệu của BA
ERD (Entity Relationship Diagram — sơ đồ thực thể quan hệ) là sơ đồ thể hiện các thực thể (entity) và mối quan hệ giữa chúng. Đây là công cụ giao tiếp quan trọng nhất giữa BA và team kỹ thuật khi bàn về dữ liệu.
Ba thành phần của ERD:
- Entity (thực thể): thường tương ứng với một bảng, vẽ thành hình chữ nhật. Ví dụ: Customer, Order, Product.
- Attribute (thuộc tính): các đặc điểm của thực thể, tương ứng với cột. Ví dụ Customer có name, email, phone.
- Relationship (mối quan hệ): đường nối giữa các thực thể, thể hiện chúng liên kết ra sao.
- Một khách hàng có thể có nhiều đơn hàng, nhưng mỗi đơn hàng chỉ thuộc về một khách hàng. Đây là quan hệ một-nhiều.
- Một sinh viên học nhiều môn, một môn có nhiều sinh viên. Đây là quan hệ nhiều-nhiều.
Tình huống thực tế
Tình huống 1: Sàn TMĐT và bài toán "đơn hàng thuộc về ai"
Một startup thương mại điện tử tại TP.HCM, tạm gọi là ShopViet, đang xây dựng hệ thống quản lý đơn hàng. Trong buổi họp thiết kế, BA mô tả requirement: "Khách hàng đặt đơn, mỗi đơn có nhiều sản phẩm, hệ thống cần biết tổng tiền".
Khi chuyển sang database, đội kỹ thuật nhận ra mô tả này còn thiếu. Họ vẽ ERD và phát hiện cần ít nhất bốn bảng: Customers, Orders, Products, và một bảng trung gian Order_Items để nối đơn hàng với sản phẩm. Lý do: một đơn hàng có nhiều sản phẩm và một sản phẩm xuất hiện trong nhiều đơn hàng — đây là quan hệ nhiều-nhiều, không thể nhét thẳng product_id vào bảng Orders.
Bảng Order_Items lưu từng dòng: đơn nào, sản phẩm nào, số lượng bao nhiêu, giá tại thời điểm mua. Chi tiết "giá tại thời điểm mua" là điểm BA dễ bỏ sót: nếu chỉ trỏ foreign key sang Products để lấy giá, thì khi sản phẩm tăng giá vào tháng sau, các đơn hàng cũ sẽ hiển thị sai giá. ShopViet từng gặp đúng lỗi này: một đợt khuyến mãi giảm giá khiến báo cáo doanh thu của các đơn cũ tự động giảm theo, sai lệch hơn 40 triệu đồng trong báo cáo tháng.
Bài học: khi mô tả requirement liên quan dữ liệu, hãy luôn hỏi "giá trị này có cần lưu lại tại thời điểm phát sinh không, hay luôn lấy giá trị mới nhất?". Hiểu foreign key và quan hệ nhiều-nhiều giúp bạn phát hiện những lỗ hổng này từ giai đoạn phân tích, trước khi chúng thành bug tốn tiền.
Tình huống 2: Ngân hàng số và primary key cho khách hàng
Một ngân hàng số tại Việt Nam triển khai ứng dụng mở tài khoản online. Ban đầu nhóm phát triển dùng số điện thoại làm định danh khách hàng vì "ai cũng có số điện thoại và nó là duy nhất". Trên ERD, họ đặt phone_number làm primary key của bảng Customers.
Vấn đề bùng phát sau sáu tháng: một khách hàng đổi số điện thoại. Vì số điện thoại là primary key và được hàng loạt bảng khác tham chiếu qua foreign key (Accounts, Transactions, Cards), việc đổi số trở thành cơn ác mộng — phải cập nhật đồng loạt mọi bảng liên quan, rủi ro mất liên kết dữ liệu rất cao. Tệ hơn, có trường hợp số điện thoại cũ bị nhà mạng thu hồi và cấp cho người khác.
Đội kiến trúc phải làm lại: tạo một customer_id nội bộ dạng số tự tăng làm primary key thật, còn phone_number chỉ là một thuộc tính thông thường có thể thay đổi.
Bài học: primary key nên là một giá trị không mang ý nghĩa nghiệp vụ và không bao giờ thay đổi (gọi là surrogate key). Là BA, khi bạn thấy team định lấy email, số điện thoại, hay CMND làm khóa chính, hãy đặt câu hỏi: "Giá trị này có thể thay đổi trong vòng đời của bản ghi không?". Nếu có, đó là tín hiệu cảnh báo về thiết kế.
Tình huống 3: Hệ thống LMS và quan hệ nhiều-nhiều
Một nền tảng học trực tuyến (giả định tương tự bối cảnh khóa học này) cần mô hình hóa việc "học viên đăng ký khóa học". BA mới vào nghề vẽ ERD với hai bảng Students và Courses, rồi đặt course_id làm foreign key trong bảng Students.
Khi review, mentor chỉ ra lỗi: cách này chỉ cho phép mỗi học viên đăng ký đúng một khóa. Nhưng nghiệp vụ thực tế là một học viên học nhiều khóa, và một khóa có nhiều học viên — quan hệ nhiều-nhiều. Giải pháp đúng là tạo bảng trung gian Enrollments (đăng ký) với hai foreign key: student_id và course_id, kèm các thuộc tính bổ sung như enrolled_date, progress_percent, completion_status.
Bảng trung gian này không chỉ giải quyết quan hệ nhiều-nhiều mà còn là nơi lý tưởng để lưu dữ liệu về chính mối quan hệ đó — ví dụ tiến độ học của một học viên trong một khóa cụ thể.
Bài học: bất cứ khi nào bạn thấy "nhiều bên này ứng với nhiều bên kia", hãy nghĩ ngay tới một bảng trung gian. Đây là mẫu thiết kế xuất hiện cực kỳ thường xuyên trong nghiệp vụ thật, và nhận ra nó là dấu hiệu của một BA hiểu dữ liệu.
Hướng dẫn từng bước
Khi bạn cần mô hình hóa dữ liệu cho một tính năng, hãy đi theo quy trình sau:
- Liệt kê các danh từ nghiệp vụ chính. Đọc lại requirement và gạch chân các danh từ quan trọng: khách hàng, đơn hàng, sản phẩm, thanh toán... Mỗi danh từ lặp lại nhiều lần thường là một entity (một bảng tiềm năng).
- Xác định thuộc tính cho từng entity. Với mỗi entity, hỏi "cần lưu những thông tin gì?". Customer cần tên, email, số điện thoại, ngày tạo. Viết chúng ra thành danh sách cột.
- Chọn primary key cho từng bảng. Ưu tiên dùng một mã định danh số tự tăng hoặc UUID, tránh dùng dữ liệu nghiệp vụ có thể thay đổi.
- Xác định mối quan hệ giữa các entity. Với từng cặp bảng, hỏi hai chiều: "Một A có thể có bao nhiêu B?" và "Một B có thể có bao nhiêu A?". Câu trả lời cho bạn biết quan hệ là một-một, một-nhiều, hay nhiều-nhiều.
- Xử lý quan hệ nhiều-nhiều bằng bảng trung gian. Mỗi khi gặp nhiều-nhiều, tạo một bảng nối chứa hai foreign key.
- Vẽ ERD và review cùng team. Dùng công cụ như draw.io, Lucidchart, hoặc dbdiagram.io để vẽ. Đưa cho dev và DBA xem để họ phản biện về tính khả thi kỹ thuật.
- Kiểm chứng bằng dữ liệu mẫu. Tự điền vài hàng dữ liệu giả vào từng bảng và thử trả lời các câu hỏi nghiệp vụ: "Đơn này của ai?", "Khách này mua những gì?". Nếu trả lời được mượt mà, mô hình của bạn đã đứng vững.
Lỗi thường gặp & mẹo
Nhầm lẫn giữa bảng và file Excel. Nhiều BA mới quen tư duy gộp tất cả vào một bảng lớn cho "tiện". Trong database, việc tách dữ liệu thành nhiều bảng liên kết (gọi là chuẩn hóa - normalization) giúp tránh trùng lặp và sai lệch. Đừng cố nhét địa chỉ, lịch sử mua hàng, thông tin thẻ vào chung một bảng Customers.
Quên cardinality khi mô tả quan hệ. Nói "khách hàng có đơn hàng" là chưa đủ. Phải nói rõ "một khách hàng có nhiều đơn hàng, một đơn chỉ thuộc một khách". Thiếu vế này, dev sẽ phải đoán, và đoán sai dẫn tới làm lại.
Dùng dữ liệu nghiệp vụ làm primary key. Như tình huống ngân hàng đã thấy, email hay số điện thoại có thể thay đổi. Luôn ưu tiên surrogate key trung lập.
Bỏ qua câu hỏi về xóa dữ liệu. Khi xóa một khách hàng, các đơn hàng của họ xử lý sao? Xóa theo, hay giữ lại và đánh dấu? Đây là requirement quan trọng mà BA nên làm rõ, vì nó ảnh hưởng tới ràng buộc foreign key.
Mẹo thực chiến: hãy tập thói quen vẽ một ERD nháp cho mọi tính năng có dữ liệu, dù chỉ trên giấy. Quá trình vẽ buộc bạn phải nghĩ về quan hệ và buộc bạn đặt những câu hỏi mà nếu không vẽ bạn sẽ bỏ sót. Một BA giỏi không cần vẽ ERD đẹp, nhưng cần vẽ ERD đúng logic nghiệp vụ.
Bài tập thực hành
Hãy thực hành với bối cảnh sau: một chuỗi quán cà phê tại Hà Nội muốn xây hệ thống tích điểm thành viên. Nghiệp vụ: khách hàng đăng ký thành viên, mỗi lần mua hàng tại một chi nhánh sẽ tạo một hóa đơn, mỗi hóa đơn cộng điểm cho khách. Một khách mua nhiều lần, một chi nhánh phục vụ nhiều khách.
- Liệt kê các entity (bảng) cần có cho hệ thống này.
- Với mỗi entity, ghi ra ít nhất ba thuộc tính và chỉ rõ primary key.
- Xác định mối quan hệ giữa các bảng và cardinality của từng quan hệ (một-nhiều hay nhiều-nhiều).
- Chỉ ra các foreign key cần thiết và chúng trỏ tới đâu.
- Vẽ ERD bằng dbdiagram.io hoặc draw.io.
- Câu hỏi nâng cao: nếu sau này quán muốn cho phép khách dùng điểm để đổi quà, bạn sẽ thêm bảng nào? Quan hệ giữa khách và quà là gì?
Tóm tắt
Trong bài này, bạn đã nắm được nền tảng về relational database — loại cơ sở dữ liệu phổ biến nhất trong doanh nghiệp. Dữ liệu được lưu trong các table gồm column (thuộc tính) và row (bản ghi). Hai khái niệm cốt lõi tạo nên tính "quan hệ" là primary key (định danh duy nhất từng hàng) và foreign key (sợi dây nối tới bảng khác). SQL là ngôn ngữ để hỏi dữ liệu, và là BA bạn chỉ cần đọc hiểu được SELECT, FROM, WHERE, JOIN là đủ tự tin.
Quan trọng nhất với vai trò BA là ERD — bản đồ thể hiện các entity và mối quan hệ giữa chúng. Nắm vững cardinality (một-một, một-nhiều, nhiều-nhiều) và biết khi nào cần bảng trung gian là kỹ năng giúp bạn viết requirement chính xác và giao tiếp hiệu quả với team kỹ thuật.
Ba tình huống thực tế — sàn TMĐT, ngân hàng số, nền tảng học trực tuyến — cho thấy những lỗi thiết kế dữ liệu phổ biến có thể gây hậu quả tốn kém ra sao, và một BA hiểu database sẽ phát hiện chúng ngay từ giai đoạn phân tích. Hãy biến việc vẽ ERD nháp thành thói quen cho mọi tính năng có dữ liệu. Ở các bài sau, chúng ta sẽ đi sâu hơn vào các loại quan hệ, SQL so với NoSQL, và các loại database chuyên biệt — nhưng nền tảng vững chắc bạn vừa xây ở bài này sẽ theo bạn suốt sự nghiệp.