1
Quiz
Kiểm tra: Finance/Kế toán sang BA
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài nàyData Modeling & ERD Reading
TechnicalĐọc và phác thảo Entity-Relationship Diagram để giao tiếp với engineering về schema, FK, normalization.
Đăng nhập để đánh dấu kỹ năng và theo dõi tiến độ.
Bạn đang ở đâu với kỹ năng này?
Làm bài Đánh giá Kỹ năng Kỹ thuật cho PM/BA — 2 người đã làm. Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Technical, không chỉ kỹ năng này.
Làm bài đánh giáKỹ năng này cho bạn điều gì
Bắt đầu từ đây
ERD là bản đồ dữ liệu: mỗi ô là một bảng, mỗi đường nối nói một bảng liên quan tới bảng kia theo kiểu nào — một-một, một-nhiều, hay nhiều-nhiều. Đọc được nó là biết trước một yêu cầu “đơn giản” có phải đơn giản thật không.
Khi đã làm được
Vẽ được ERD nháp cho một tính năng trước khi viết spec, nhận ra khi một yêu cầu đang đổi quan hệ từ 1:N sang N:M (đó là lúc chi phí nhảy vọt), và hỏi dev đúng câu về dữ liệu lịch sử thay vì chỉ hỏi “mất bao lâu”.
Roadmap — Cách học và đạt kỹ năng
Data Modeling & ERD Reading là gì?
ERD (Entity-Relationship Diagram) là bản đồ các bảng dữ liệu và cách chúng nối với nhau.
Vì sao người không viết code vẫn cần đọc: phần lớn “tưởng đơn giản mà hoá ra hai tuần” là vì quan hệ dữ liệu, không phải vì giao diện.
Ba kiểu quan hệ — và cái nào khiến chi phí nhảy vọt
| Quan hệ | Ví dụ | Chi phí đổi |
|---|---|---|
| 1:1 | Một người dùng — một hồ sơ | Thấp |
| 1:N | Một người dùng — nhiều đơn hàng | Thấp, đây là mặc định |
| N:M | Một đơn — nhiều sản phẩm, một sản phẩm — nhiều đơn | Cao: cần bảng trung gian, sửa nhiều chỗ |
Câu hỏi đáng giá nhất bạn có thể hỏi trong một buổi refinement: “Cái này có biến quan hệ từ một-nhiều thành nhiều-nhiều không?”
Khi nào bạn gặp chuyện này
| Tình huống | Bạn làm gì | Nếu không |
|---|---|---|
| “Cho phép người dùng lưu nhiều địa chỉ giao hàng.” | Vẽ nháp: users 1—N addresses. Hỏi thêm: đơn cũ phải giữ địa chỉ lúc đặt hay trỏ tới địa chỉ hiện tại? | Đội làm kiểu trỏ, rồi người dùng sửa địa chỉ và mọi hoá đơn cũ đổi theo. |
| “Một sản phẩm có thể thuộc nhiều danh mục.” | Nhận ra đây là N:M — cần bảng trung gian. Hỏi ngay về ảnh hưởng tới tìm kiếm và báo cáo. | Ước lượng 2 ngày, làm mất 2 tuần, và không ai giải thích được vì sao. |
| “Thêm một trường nhỏ thôi mà.” | Hỏi trường đó có cần lịch sử không. Nếu có, đó không phải một cột — đó là một bảng. | Sáu tháng sau cần báo cáo theo thời gian và dữ liệu cũ đã bị ghi đè, không lấy lại được. |
Tại sao PM cần biết ERD
Nhiều PM hỏi feature đơn giản nhưng schema underlying lại bắt engineering rewrite migration tốn 2 tuần. Đọc được ERD = ra quyết định "feasibility-aware" trước khi commit timeline.
Core concepts
- Entity — table (vd:
users,orders). - Attribute — column.
- Primary key (PK) — định danh duy nhất một row.
- Foreign key (FK) — link sang entity khác.
- Cardinality — 1:1, 1:N, N:M.
- Normalization — 1NF/2NF/3NF, tránh redundancy.
Ví dụ — E-commerce simplified
users (id PK, email, name, created_at) orders (id PK, user_id FK, total, status, created_at) order_items (id PK, order_id FK, product_id FK, qty, price) products (id PK, name, price, stock)
Cardinality: 1 user — N orders. 1 order — N order_items. 1 product — N order_items.
Notation
- Crow's foot — chân chim cho "many", thẳng cho "one".
- UML — số 0..1, 1, *, 1..*.
Bốn câu hỏi trước khi chốt một yêu cầu dữ liệu
| Câu hỏi | Vì sao hỏi | Câu trả lời xấu nghĩa là gì |
|---|---|---|
| Một X có bao nhiêu Y, và ngược lại? | Xác định 1:N hay N:M | “Ờ thì nhiều” → cần hỏi tiếp |
| Có cần giữ giá trị tại thời điểm không? | Quyết định copy hay trỏ | “Chắc không cần” → sáu tháng sau sẽ cần |
| Xoá X thì Y ra sao? | Lộ ràng buộc ẩn | “Chưa nghĩ tới” → sẽ thành lỗi dữ liệu |
| Dữ liệu cũ xử lý thế nào? | Migration là phần đắt nhất | “Để sau” → là phần lâu nhất |
Sai lầm thường gặp
| Sai lầm | Vì sao hỏng | Làm thay bằng |
|---|---|---|
| Chỉ hỏi “mất bao lâu” | Bạn nhận một con số mà không hiểu vì sao. | Hỏi quan hệ dữ liệu trước, thời gian sau. |
| Bỏ qua dữ liệu lịch sử | Migration thường tốn hơn tính năng. | Hỏi ngay từ đầu. |
| Nhầm “thêm cột” với “thêm bảng” | Thứ cần lịch sử không bao giờ là một cột. | Hỏi “có cần biết giá trị này hôm qua không?” |
| Vẽ ERD sau khi viết spec | Spec đã hứa thứ schema không đỡ nổi. | Vẽ nháp trước. |
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Business Analyst | Đây là kỹ năng trung tâm của bạn — yêu cầu nghiệp vụ luôn là phát biểu về dữ liệu. |
| Product Manager | Bạn không thiết kế schema, nhưng bạn cam kết timeline dựa trên nó. |
| Product Owner | Acceptance criteria không nói rõ quan hệ dữ liệu là criteria sẽ bị hiểu hai cách. |
| Technical Product Manager | Bạn là người dịch giữa mô hình dữ liệu và hệ quả sản phẩm. |
Definition of done — dấu hiệu bạn đã đạt
- Bạn vẽ được ERD nháp cho một tính năng trước khi viết spec.
- Bạn nhận ra N:M khi nghe một yêu cầu, không phải khi dev báo lại.
- Bạn luôn hỏi về dữ liệu lịch sử và migration.
- Ước lượng của đội ít bị vỡ vì lý do “schema không đỡ được”.
Vì sao người làm sản phẩm cần đọc được mô hình dữ liệu
Bạn không cần thiết kế cơ sở dữ liệu. Nhưng mô hình dữ liệu quyết định thứ sản phẩm có thể làm được, và bạn sẽ liên tục va vào nó mà không hiểu vì sao.
| Câu hỏi nghiệp vụ nghe đơn giản | Mô hình dữ liệu quyết định điều gì |
|---|---|
| "Một khách hàng có nhiều địa chỉ giao hàng được không?" | Một-nhiều hay một-một — đổi về sau rất đắt |
| "Xem được lịch sử giá cũ không?" | Có lưu vết thay đổi hay ghi đè — nếu ghi đè thì dữ liệu cũ đã mất vĩnh viễn |
| "Một người có thể thuộc hai phòng ban không?" | Nhiều-nhiều — thường bị bỏ sót lúc thiết kế đầu |
| "Xoá khách hàng thì đơn hàng cũ thế nào?" | Xoá mềm hay xoá cứng — ảnh hưởng cả báo cáo lẫn pháp lý |
Điểm quan trọng nhất: những câu hỏi này rẻ để trả lời lúc thiết kế và rất đắt để đổi sau khi đã có dữ liệu thật. Một yêu cầu "cho phép nhiều địa chỉ" đến sau một năm có thể là vài tuần công việc, trong khi lúc đầu chỉ là một lựa chọn.
Bốn câu hỏi nên hỏi khi đọc một mô hình
- Quan hệ này là một-nhiều hay nhiều-nhiều? Nhiều-nhiều hay bị mô hình nhầm thành một-nhiều vì lúc đầu chưa ai nghĩ tới ngoại lệ.
- Cái gì xảy ra khi xoá? Dữ liệu liên quan biến mất, hay bị giữ lại mồ côi, hay chặn không cho xoá.
- Có lưu lịch sử không? Nếu giá, trạng thái hay quyền hạn thay đổi theo thời gian mà chỉ lưu giá trị hiện tại, mọi báo cáo về quá khứ đều sai.
- Trường nào bắt buộc, trường nào không? Trường không bắt buộc sẽ trống ở phần lớn bản ghi — và mọi tính năng dựa vào nó sẽ hoạt động với phần nhỏ dữ liệu.
Câu thứ ba là câu cứu nhiều dự án nhất. Rất nhiều báo cáo sai không phải vì tính nhầm — mà vì dữ liệu gốc đã bị ghi đè và không còn cách nào biết quá khứ.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Business Analyst | Bạn phát hiện quan hệ nhiều-nhiều bị mô hình nhầm — lỗi đắt nhất và khó sửa nhất về sau |
| Product Owner | Biết yêu cầu nào rẻ và yêu cầu nào đắt, trước khi hứa với khách |
| Engineer | Bạn thiết kế, nhưng bạn cần câu hỏi nghiệp vụ đúng để thiết kế đúng |
| QA | Hành vi khi xoá và ca dữ liệu mồ côi là nhóm lỗi hay bị bỏ sót nhất |
| Người làm báo cáo | Không lưu lịch sử nghĩa là mọi báo cáo về quá khứ đều không đáng tin |
Definition of done
- Mọi quan hệ đã được xác nhận là một-nhiều hay nhiều-nhiều, kèm ví dụ thật.
- Đã quyết hành vi khi xoá cho từng thực thể.
- Đã xác định trường nào cần lưu lịch sử thay đổi.
- Trường bắt buộc và không bắt buộc được phân biệt rõ, có tính tới dữ liệu cũ.
- Đã kiểm mô hình bằng 3–5 câu hỏi nghiệp vụ thật thay vì chỉ xem sơ đồ.
Tự kiểm 3 câu
Đọc xong rồi thì thử xem — đúng cả ba là đạt.Khóa học liên quan (3)
Sử dụng trong vai trò
Kiểm tra kỹ năng này
Bài kiểm tra của các khóa dạy kỹ năng này
2
Quiz
Chương 2: API nâng cao & Kiến trúc hệ thống cho BA
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
3
Quiz
Bài thi tổng kết: Data Modeling and ERD Mastery
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
4
Quiz
Bài thi tổng kết: Technical BA Masterclass
Bài kiểm tra của một khóa dạy kỹ năng này.
Làm bài này
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.