Mở đầu — vì sao bài này quan trọng
Chúng ta đã đi qua 48 bài học. Bạn đã hiểu entity, attribute, primary key, relationship, cardinality; đã phân biệt được ba tầng mô hình conceptual — logical — physical; đã chuẩn hóa tới 3NF rồi biết khi nào cần denormalize; đã dựng ERD cho ngân hàng, e-commerce, insurance, LMS; đã đụng tới indexes, constraints, audit table, temporal data, JSON, star schema và cả PDPL. Đó là một kho công cụ đồ sộ. Nhưng có một sự thật phũ phàng mà mọi mentor đều phải nói thẳng với học viên: sở hữu công cụ không đồng nghĩa với biết làm nghề.
Trong công việc thật của một Business Analyst chuyên về dữ liệu, không ai đưa cho bạn một đề bài gọn gàng kiểu "hãy chuẩn hóa bảng này tới 3NF". Thay vào đó, sếp hoặc khách hàng ném cho bạn một câu mơ hồ: "Bên mình sắp làm ví điện tử, em lo phần mô hình dữ liệu nhé." Từ câu nói đó tới một ERD hoàn chỉnh, có thể bàn giao cho đội kỹ thuật, là cả một hành trình mà không bài lý thuyết đơn lẻ nào dạy trọn vẹn được. Đó chính là lý do tồn tại của Capstone Project — đồ án tốt nghiệp.
Bài 49 này không dạy thêm kỹ thuật mới. Nhiệm vụ của nó là giúp bạn thiết lập (setup) đồ án tốt nghiệp: hiểu bối cảnh, xác định phạm vi, chuẩn bị công cụ, lập kế hoạch làm việc và biết mình sẽ được đánh giá theo tiêu chí nào. Nói cách khác, đây là bài "khởi động động cơ" trước khi bạn tự mình chạy hết chặng đường trong các bài tiếp theo (Bài 58 sẽ là template nộp bài cuối cùng). Làm tốt bước setup này quyết định 50% chất lượng đồ án — vì một dự án được phạm vi hóa rõ ràng và có kế hoạch tốt gần như không bao giờ đi lạc.
Khái niệm cốt lõi
Capstone Project là gì và khác gì bài tập thường?
Bài tập trong từng bài học là luyện cơ bắp riêng lẻ — hôm nay tập 2NF, mai tập cardinality. Capstone là trận đấu thật, nơi bạn phải huy động mọi cơ bắp cùng lúc, theo đúng trình tự, dưới áp lực của một bối cảnh nghiệp vụ có thật. Ba điểm khác biệt cốt lõi:
- Tính đầu-cuối (end-to-end): Bạn đi từ yêu cầu nghiệp vụ mơ hồ → conceptual model → logical model → physical model, kèm data dictionary và tài liệu giải thích. Không ai cắt sẵn khúc giữa cho bạn.
- Tính đánh đổi (trade-off): Bạn sẽ phải tự quyết định: dùng surrogate key hay natural key? Denormalize bảng số dư để đọc nhanh hay giữ chuẩn hóa để nhất quán? Không có đáp án "đúng tuyệt đối", chỉ có lựa chọn hợp lý và được bảo vệ bằng lập luận.
- Tính bàn giao (hand-off): Sản phẩm cuối phải đủ rõ để một developer chưa từng nói chuyện với bạn vẫn dựng được database từ nó.
Bối cảnh đồ án: WalletViet
Toàn bộ đồ án tốt nghiệp của khóa này xoay quanh một tình huống giả định nhưng rất sát thực tế Việt Nam:
> Bạn là BA cho một startup FinTech mới thành lập đang chuẩn bị ra mắt "WalletViet" — một ví điện tử nội địa cạnh tranh trực tiếp với MoMo, ZaloPay, ShopeePay. Sản phẩm cần cho phép người dùng: nạp/rút tiền, chuyển tiền P2P, thanh toán hóa đơn (điện, nước, internet), quét QR thanh toán tại cửa hàng, và giữ số dư ví. Đội kỹ thuật cần một mô hình dữ liệu vững chắc trước khi viết dòng code đầu tiên.
Vì sao chọn ví điện tử? Vì nó ép bạn chạm vào gần như mọi thứ đã học: tiền tệ (Bài 27), thời gian và múi giờ cho giao dịch (Bài 28), audit table cho mọi biến động số dư (Bài 22), constraints và business rule cho quy tắc "số dư không âm" (Bài 24), quan hệ nhiều-nhiều giữa người dùng và người thụ hưởng, và đặc biệt là PDPL (Bài 47) vì đây là dữ liệu tài chính cá nhân nhạy cảm bậc nhất.
Bốn "trụ" của một Capstone Setup tốt
Một buổi setup đồ án nghiêm túc phải trả lời được bốn câu hỏi, tôi gọi là 4S:
- Scenario — Tôi đang giải bài toán nghiệp vụ nào, cho ai?
- Scope — Cái gì nằm trong và cái gì nằm ngoài phạm vi của tôi? (đây là phần dễ bị bỏ qua nhất và cũng gây chết đồ án nhiều nhất)
- Setup — Tôi dùng công cụ gì (dbdiagram, draw.io, Mermaid), tổ chức file thư mục ra sao?
- Standard — Tôi sẽ được chấm theo rubric nào, deliverable gồm những gì?
Tình huống thực tế
Tình huống 1 — Startup "nuốt" quá nhiều phạm vi và trễ deadline
Một nhóm 4 bạn học viên khóa trước nhận đề WalletViet. Ngay buổi đầu, họ hào hứng liệt kê ra 23 entity: từ ví, giao dịch, người dùng, cho tới cả chương trình khách hàng thân thiết, điểm thưởng, mã giảm giá, chatbot hỗ trợ, log đăng nhập thiết bị... Sau hai tuần, họ có một ERD 23 bảng rối như mạng nhện, không kịp làm data dictionary, và không bảo vệ được vì sao lại thiết kế như vậy.
Diễn giải: Vấn đề không phải họ dốt — họ giỏi là đằng khác. Vấn đề là họ không phạm vi hóa (scoping). Trong FinTech thật, một ví điện tử ở phiên bản MVP (Minimum Viable Product) chỉ cần lõi: users, wallets, transactions, payment_methods, beneficiaries, merchants, và một transaction_ledger cho audit. Chương trình điểm thưởng là "phase 2", hoàn toàn có thể ghi vào mục Out of scope và giải thích rằng nó sẽ được mô hình hóa sau.
Bài học rút ra: Một BA giỏi được đánh giá qua thứ họ quyết định KHÔNG làm nhiều như thứ họ làm. Setup đồ án là lúc bạn đóng cọc ranh giới phạm vi — trước khi vẽ bất kỳ hình chữ nhật nào.
Tình huống 2 — Chọn sai công cụ, mất trắng công sức
Một học viên khác, anh Tuấn, quyết định vẽ toàn bộ ERD WalletViet bằng PowerPoint vì "quen tay". Đến khi giảng viên yêu cầu bổ sung 3 entity và đổi một quan hệ 1-N thành N-N, anh phải kéo lại từng mũi tên bằng chuột, lệch chỗ này hở chỗ kia, và bản vẽ cuối cùng trông thiếu chuyên nghiệp. Trong khi đó, một bạn khác dùng dbdiagram.io — khai báo bảng bằng code, thêm entity chỉ mất 3 dòng, đổi quan hệ chỉ sửa một ký hiệu > thành <>, và xuất được cả SQL DDL lẫn hình PNG chỉ trong vài giây.
Diễn giải: Với đồ án dữ liệu, công cụ diagram-as-code (dbdiagram, Mermaid ERD — nhớ lại Bài 43) vượt trội công cụ kéo-thả cho việc lặp đi lặp lại chỉnh sửa, vốn là bản chất của mọi dự án mô hình hóa. Số dư thời gian tiết kiệm được, anh Tuấn lẽ ra đã dành cho việc viết data dictionary và lập luận thiết kế — thứ thực sự được chấm điểm.
Bài học rút ra: Chọn công cụ ngay từ bước setup, ưu tiên loại cho phép version-control (lưu file .dbml hay .mmd vào Git). Công cụ sai làm bạn kiệt sức ở những việc lẽ ra máy làm.
Tình huống 3 — Không chốt "định nghĩa hoàn thành", bảo vệ đồ án lúng túng
Nhóm của bạn Linh làm ERD WalletViet rất đẹp, chuẩn hóa tới 3NF gọn gàng. Nhưng khi hội đồng hỏi: "Với giao dịch chuyển tiền thất bại giữa chừng, dữ liệu của em xử lý thế nào? Số dư của người gửi và người nhận đảm bảo nhất quán ra sao?" — cả nhóm ú ớ. Họ đã mô hình transactions với một cột status, nhưng chưa từng định nghĩa rõ đồ án của mình cần đáp ứng những kịch bản nghiệp vụ nào ngay từ đầu.
Diễn giải: Đây là hậu quả của việc bỏ qua trụ Standard trong 4S. Nếu ngay lúc setup, nhóm đã viết ra danh sách các use case bắt buộc phải mô hình được (nạp tiền, chuyển P2P thành công, chuyển P2P thất bại và hoàn tiền, thanh toán merchant qua QR...), thì họ đã tự kiểm tra được ERD trước khi bảo vệ.
Bài học rút ra: Định nghĩa tiêu chí "hoàn thành" (Definition of Done) và các kịch bản kiểm thử ngay từ bước setup. Đồ án không chỉ để "vẽ cho đẹp" mà để chứng minh mô hình chịu được nghiệp vụ thật.
Hướng dẫn từng bước
Dưới đây là quy trình 7 bước để bạn tự setup đồ án WalletViet của mình. Hãy làm tuần tự — đừng nhảy tới bước vẽ ERD trước khi xong bước 3.
Bước 1 — Đọc và tóm tắt bối cảnh nghiệp vụ (1 trang). Viết bằng lời của chính bạn: WalletViet là gì, phục vụ ai, giải quyết vấn đề gì, cạnh tranh với ai. Ghi rõ 5 nhóm chức năng lõi: nạp/rút, chuyển P2P, thanh toán hóa đơn, thanh toán QR merchant, quản lý số dư. Việc diễn đạt lại giúp bạn phát hiện chỗ mình chưa hiểu.
Bước 2 — Xác định các bên liên quan (stakeholders) và use case. Liệt kê actor: người dùng cá nhân, merchant (cửa hàng), ngân hàng liên kết, hệ thống đối tác thanh toán hóa đơn, đội vận hành nội bộ. Với mỗi actor, ghi ra 2–3 use case chính. Đây là nguồn để bạn nhận diện entity ở bước sau.
Bước 3 — Chốt phạm vi (In scope / Out of scope). Lập một bảng hai cột dứt khoát. Ví dụ:
| In scope (MVP) | Out of scope (phase sau) |
|---|---|
| Ví, số dư, giao dịch cốt lõi | Điểm thưởng, khách hàng thân thiết |
| Chuyển P2P, nạp/rút, thanh toán merchant | Cho vay, đầu tư trong ví |
| Audit ledger, KYC cơ bản | Chatbot, hệ thống ticket hỗ trợ |
| Tuân thủ PDPL cho dữ liệu cá nhân | Báo cáo BI / data warehouse |
Bước 4 — Nhận diện danh sách entity ứng viên (candidate entities).
Từ use case, gạch chân các danh từ nghiệp vụ. Dự kiến bạn sẽ có khoảng 8–12 entity lõi: users, wallets, transactions, transaction_ledger, payment_methods, beneficiaries, merchants, bill_payments, kyc_documents. Đừng vội định nghĩa attribute — chỉ cần tên và một câu mô tả mỗi entity.
Bước 5 — Chọn công cụ và dựng khung file. Quyết định dùng dbdiagram.io (khuyến nghị) hoặc Mermaid. Tạo cấu trúc thư mục đồ án:
walletviet-capstone/
├── 01-context.md (bối cảnh + scope)
├── 02-use-cases.md
├── 03-conceptual.dbml (mô hình khái niệm)
├── 04-logical.dbml
├── 05-physical.sql (DDL cho DBMS cụ thể, vd MySQL/PostgreSQL)
├── 06-data-dictionary.md
└── 07-design-decisions.md (lập luận các trade-off)
Đưa thư mục này vào Git ngay từ đầu để theo dõi phiên bản.
Bước 6 — Lập kế hoạch và mốc thời gian. Chia đồ án thành các mốc bám theo các bài đã học: (1) Conceptual model, (2) Logical + normalization, (3) Physical + indexes/constraints, (4) Data dictionary, (5) Design decisions & rà soát PDPL. Gán deadline nhỏ cho từng mốc thay vì một deadline lớn cuối cùng.
Bước 7 — Viết Definition of Done và bộ kịch bản kiểm thử. Ghi rõ đồ án được coi là "xong" khi mô hình đáp ứng được ít nhất các kịch bản: nạp tiền thành công, chuyển P2P thành công, chuyển P2P thất bại và hoàn tiền, thanh toán merchant qua QR, truy vết toàn bộ biến động số dư của một ví. Đây là "bài kiểm tra" bạn tự đặt ra cho chính mô hình của mình.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào vẽ bảng. Đây là cám dỗ lớn nhất. Vẽ trước khi phạm vi hóa giống như xây nhà trước khi có bản vẽ móng. Mẹo: Ép bản thân hoàn thành file 01-context.md và bảng scope trước khi mở công cụ diagram.
Lỗi 2 — Phạm vi phình to (scope creep). Cứ thêm "cho có" một entity điểm thưởng, rồi mã giảm giá, rồi... Mẹo: Mỗi khi muốn thêm entity, hỏi: "Nó có phục vụ trực tiếp một use case trong scope không?" Nếu không, đẩy sang cột out-of-scope.
Lỗi 3 — Quên yếu tố tuân thủ pháp lý. Với FinTech Việt Nam, dữ liệu KYC (CCCD, số điện thoại, khuôn mặt) chịu điều chỉnh của Nghị định bảo vệ dữ liệu cá nhân. Bỏ qua ngay từ setup nghĩa là phải đập đi làm lại. Mẹo: Ghi một dòng "compliance note" trong scope, đánh dấu entity nào chứa PII (Personally Identifiable Information).
Lỗi 4 — Chọn công cụ không version-control được. Mẹo: Ưu tiên định dạng text (.dbml, .mmd, .sql) để commit vào Git, dễ so sánh thay đổi qua từng phiên bản.
Lỗi 5 — Không ghi lại lý do quyết định. Sáu tuần sau bạn sẽ quên vì sao chọn surrogate key cho transactions. Mẹo: Mỗi lần ra một quyết định thiết kế, ghi ngay một dòng vào 07-design-decisions.md theo mẫu: "Quyết định — Lý do — Đánh đổi chấp nhận".
Mẹo vàng: Hãy coi 07-design-decisions.md là "bảo hiểm bảo vệ đồ án". Khi hội đồng chất vấn, bạn chỉ cần mở file này ra là có sẵn lập luận. Một BA chuyên nghiệp luôn ghi lại tư duy, không chỉ ghi lại kết quả.
Bài tập thực hành
Đây là bài tập setup — bạn chưa cần vẽ ERD hoàn chỉnh, chỉ cần chuẩn bị nền móng cho các bài sau.
- Viết context brief (nửa trang): Diễn đạt lại bằng lời của bạn: WalletViet là gì, ba đối thủ cạnh tranh, và năm nhóm chức năng lõi.
- Lập bảng scope: Tạo bảng In scope / Out of scope với tối thiểu 5 dòng mỗi cột. Mỗi mục out-of-scope kèm một câu giải thích lý do hoãn.
- Liệt kê actor và use case: Nêu ít nhất 4 actor, mỗi actor 2 use case. Gạch chân các danh từ nghiệp vụ xuất hiện — đó là entity ứng viên.
- Lập danh sách 8–10 entity ứng viên: Chỉ ghi tên + một câu mô tả mỗi entity. Chưa cần attribute.
- Dựng khung thư mục đồ án theo mẫu ở Bước 5 và khởi tạo một Git repo trống với 7 file (có thể để trống nội dung, chỉ cần cấu trúc).
- Viết Definition of Done: Liệt kê 5 kịch bản nghiệp vụ mà mô hình cuối cùng bắt buộc phải xử lý được, trong đó có ít nhất một kịch bản thất bại/hoàn tiền.
- Thử thách nâng cao: Đánh dấu trong danh sách entity ứng viên những entity nào chứa PII, và viết một câu ghi chú compliance về cách bạn dự định bảo vệ dữ liệu đó (mã hóa, tách bảng, hạn chế truy cập) — chuẩn bị cho phần PDPL.
Tóm tắt
Bài 49 không dạy kỹ thuật mới — nó dạy bạn cách bắt đầu một đồ án dữ liệu thực thụ đúng cách. Chúng ta đã dùng bối cảnh WalletViet, một ví điện tử nội địa cạnh tranh với MoMo và ZaloPay, làm sân chơi để tổng hợp toàn bộ kiến thức đã học.
Những điểm cần khắc cốt ghi tâm:
- Capstone khác bài tập thường ở ba điểm: tính đầu-cuối, tính đánh đổi, và tính bàn giao. Bạn phải huy động mọi kỹ năng cùng lúc.
- Khung 4S — Scenario, Scope, Setup, Standard — là kim chỉ nam cho mọi buổi setup đồ án.
- Phạm vi hóa là quyết định quan trọng nhất. Một BA giỏi được đánh giá qua thứ họ quyết định không làm. Đóng cọc In scope / Out of scope trước khi vẽ.
- Chọn công cụ diagram-as-code (dbdiagram, Mermaid) để dễ chỉnh sửa và version-control; đừng phí sức vào PowerPoint.
- Ghi lại tư duy, không chỉ ghi kết quả: file design-decisions và Definition of Done là bảo hiểm cho buổi bảo vệ đồ án.