Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận bàn giao một hệ thống cũ. Trong database có một cột tên là status trong bảng orders. Giá trị của nó là những con số: 0, 1, 2, 5, 9. Không có ai trong nhóm hiện tại biết 5 nghĩa là gì. Tài liệu thì không có. Người viết code đã nghỉ việc từ hai năm trước. Bạn phải mở từng đoạn code, dò ngược logic, hỏi vòng vòng khắp công ty chỉ để hiểu một con số. Một buổi chiều biến mất.
Đây chính xác là vấn đề mà Data Dictionary (từ điển dữ liệu) sinh ra để giải quyết. Trong các bài trước, bạn đã học cách dựng entity, đặt attribute, chọn primary key và vẽ quan hệ. Nhưng một mô hình dữ liệu đẹp trên giấy vẫn chưa đủ. Khi đội phát triển bắt tay vào code, khi đội kiểm thử viết test case, khi BA mới vào dự án cần hiểu hệ thống — tất cả họ đều cần một nguồn sự thật duy nhất mô tả từng phần tử dữ liệu nghĩa là gì, kiểu gì, ràng buộc ra sao.
Data Dictionary là tài liệu đó. Với vai trò Business Analyst, kỹ năng xây dựng và duy trì data dictionary là một trong những deliverable thuyết phục nhất bạn có thể tạo ra — nó biến mô hình trừu tượng thành thứ mà cả người kinh doanh lẫn lập trình viên đều dùng được hằng ngày.
Khái niệm cốt lõi
Data Dictionary là gì?
Data Dictionary là tài liệu mô tả đầy đủ và có cấu trúc về mọi phần tử dữ liệu (data element) trong hệ thống. Nói cách khác, nếu mô hình ERD trả lời câu hỏi "hệ thống có những thực thể nào và chúng liên kết với nhau ra sao?", thì data dictionary trả lời câu hỏi sâu hơn: "từng thuộc tính cụ thể là cái gì, lưu kiểu dữ liệu nào, bắt buộc hay không, giá trị hợp lệ là gì, và ý nghĩa nghiệp vụ ra sao?"
Hãy phân biệt rõ: ERD là bức tranh tổng thể, data dictionary là chú thích chi tiết cho từng nét vẽ. Hai thứ này bổ trợ nhau chứ không thay thế nhau.
Một mục từ (entry) trong data dictionary gồm gì?
Mỗi attribute trong hệ thống tương ứng một dòng trong data dictionary. Các cột (thuộc tính mô tả) phổ biến và nên có:
- Tên kỹ thuật (Field/Column name): tên dùng trong database, ví dụ
customer_id,order_total. - Tên nghiệp vụ (Business name): tên con người đọc hiểu, ví dụ "Mã khách hàng", "Tổng giá trị đơn hàng".
- Mô tả (Description): giải thích ngắn gọn ý nghĩa nghiệp vụ. Đây là cột quý giá nhất nhưng hay bị bỏ trống.
- Kiểu dữ liệu (Data type):
VARCHAR(50),DECIMAL(15,2),DATE,BOOLEAN... - Độ dài / Định dạng (Length/Format): ví dụ số CCCD 12 chữ số, ngày theo
YYYY-MM-DD. - Bắt buộc (Nullable / Required): cột này có cho phép trống không?
- Giá trị hợp lệ (Allowed values / Domain): với cột
status, đây là nơi ghi rõ 0 = Mới, 1 = Đã xác nhận, 2 = Đang giao... - Giá trị mặc định (Default): ví dụ
created_atmặc định là thời điểm hiện tại. - Khóa (Key): PK, FK, hay unique. Nếu là FK thì trỏ tới bảng nào.
- Quy tắc nghiệp vụ (Business rule / Validation): ví dụ "tuổi phải ≥ 18", "email phải đúng định dạng".
- Nguồn dữ liệu (Source): dữ liệu nhập tay, sinh tự động, hay đến từ hệ thống khác.
- Ví dụ (Sample value): một giá trị mẫu giúp người đọc hình dung ngay.
Đối tượng sử dụng và lý do họ cần
Data dictionary phục vụ nhiều nhóm cùng lúc, và hiểu ai dùng để làm gì sẽ giúp bạn viết đúng trọng tâm:
- Lập trình viên (Developers): dùng nó như tài liệu tham chiếu khi implement. Họ tra cứu kiểu dữ liệu, ràng buộc, giá trị mặc định mà không phải hỏi đi hỏi lại BA.
- Business Analyst: dùng nó để liên kết yêu cầu nghiệp vụ với mô hình dữ liệu, và để onboard người mới.
- Tester / QA: dùng cột "giá trị hợp lệ" và "quy tắc nghiệp vụ" để thiết kế test case biên (boundary), test case âm (negative).
- Đội vận hành & phân tích dữ liệu: dùng để viết báo cáo, query đúng nghĩa cột.
- Đội tuân thủ & bảo mật: dùng để biết cột nào chứa dữ liệu cá nhân cần bảo vệ.
Hai loại data dictionary
Có hai dạng cần phân biệt. Active data dictionary là loại được quản lý ngay trong chính DBMS — hệ quản trị cơ sở dữ liệu tự sinh và cập nhật metadata (kiểu cột, ràng buộc) khi schema thay đổi. Passive (hoặc static) data dictionary là tài liệu do con người viết và duy trì riêng, thường là một file spreadsheet hoặc trang wiki. Với vai trò BA, bạn chủ yếu làm việc với loại thứ hai — vì nó chứa phần ý nghĩa nghiệp vụ mà DBMS không bao giờ tự sinh ra được.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử Tiki và cột "status" mơ hồ
Một nhóm BA tại một công ty thương mại điện tử ở TP.HCM (giả định lấy cảm hứng từ mô hình Tiki) nhận dự án nâng cấp module quản lý đơn hàng. Bảng orders có cột order_status kiểu TINYINT. Khi rà soát, nhóm phát hiện trong dữ liệu thực tế có tới 8 giá trị khác nhau, nhưng tài liệu cũ chỉ ghi 4. Ba developer khác nhau đã thêm trạng thái mới mà không ai cập nhật tài liệu.
Hậu quả: báo cáo doanh thu đếm sai số đơn "đã hoàn thành" vì giá trị 7 (đơn hoàn tất nhưng có hoàn một phần) bị bỏ sót. Sai lệch lên tới khoảng 3% doanh thu tháng — một con số đủ lớn để ban giám đốc đặt câu hỏi.
Nhóm BA giải quyết bằng cách xây một data dictionary chuẩn cho bảng orders, trong đó cột order_status được liệt kê đầy đủ: 1 = Chờ thanh toán, 2 = Đã thanh toán, 3 = Đang đóng gói, 4 = Đang giao, 5 = Giao thành công, 6 = Đã hủy, 7 = Hoàn một phần, 8 = Hoàn toàn bộ. Mỗi giá trị kèm mô tả nghiệp vụ và quy tắc chuyển trạng thái.
Bài học: cột mã hóa bằng số là "mìn nổ chậm" nếu không có data dictionary. Giá trị hợp lệ (allowed values) phải được ghi tập trung một chỗ và cập nhật mỗi khi thêm trạng thái mới.
Ví dụ 2 — Ngân hàng và cột số tài khoản tưởng đơn giản
Tại một ngân hàng thương mại cổ phần ở Hà Nội, đội tích hợp xây API kết nối hệ thống core banking với một ví điện tử đối tác. Trong data dictionary của bảng accounts, cột account_number ban đầu được mô tả sơ sài: "Số tài khoản, kiểu chuỗi".
Khi đối tác đọc tài liệu này, họ giả định số tài khoản là số nguyên và lưu bằng kiểu INTEGER ở phía họ. Vấn đề: số tài khoản của ngân hàng có thể bắt đầu bằng số 0 (ví dụ 0123456789), và khi lưu dạng số nguyên, số 0 đầu bị mất, khiến giao dịch chuyển nhầm tài khoản.
Sau sự cố, BA viết lại mục từ cho account_number với độ chi tiết cao: kiểu VARCHAR(20), định dạng "chuỗi chữ số, có thể bắt đầu bằng 0, không chứa dấu cách", quy tắc nghiệp vụ "luôn lưu và truyền dưới dạng chuỗi, tuyệt đối không ép sang số", kèm giá trị mẫu 0123456789.
Bài học: với dữ liệu định danh (mã số), cột mô tả định dạng và quy tắc xử lý quan trọng ngang với kiểu dữ liệu. Một dòng mô tả mơ hồ có thể gây sự cố tài chính thật. Data dictionary là nơi chặn hiểu lầm này từ trước khi viết code.
Ví dụ 3 — Startup giao đồ ăn và việc onboard nhân sự mới
Một startup giao đồ ăn quy mô vừa ở Đông Nam Á tăng trưởng nhanh, tuyển thêm 5 developer trong một quý. Mỗi developer mới mất trung bình 2 tuần chỉ để hiểu cấu trúc dữ liệu, chủ yếu bằng cách hỏi đồng nghiệp và đọc code rời rạc. Nhân với 5 người và lương kỹ sư, chi phí "mò mẫm" này là đáng kể.
BA dẫn dắt việc xây data dictionary cho 12 bảng cốt lõi (restaurants, menu_items, orders, riders, deliveries...), lưu trên Confluence, mỗi bảng một trang. Sau đó, thời gian onboard một developer mới giảm từ 2 tuần xuống còn khoảng 4 ngày, vì họ đọc được "bức tranh dữ liệu" có hệ thống ngay từ đầu.
Bài học: giá trị lớn nhất của data dictionary thường không nằm ở lúc thiết kế ban đầu, mà ở khả năng truyền đạt kiến thức khi đội ngũ thay đổi. Nó là tài sản tri thức (knowledge asset) của tổ chức, không phải thủ tục giấy tờ.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để xây một data dictionary từ con số 0:
Bước 1 — Xác định phạm vi. Đừng cố tài liệu hóa toàn bộ database trong một lần nếu nó quá lớn. Bắt đầu từ các bảng cốt lõi (core entities) mà nghiệp vụ phụ thuộc nhiều nhất. Ví dụ với e-commerce: bắt đầu từ customers, products, orders trước.
Bước 2 — Chọn công cụ và định dạng. Với đa số dự án, một file spreadsheet (Google Sheets, Excel) là đủ và dễ chia sẻ nhất. Mỗi sheet là một bảng, mỗi dòng là một cột. Nếu công ty dùng wiki nội bộ như Confluence hoặc Notion, hãy đặt nó ở đó để dễ liên kết với tài liệu yêu cầu. Một số ERD tool (như dbdiagram, mà bạn đã làm quen ở bài trước) cũng cho phép gắn ghi chú trực tiếp vào cột.
Bước 3 — Thống nhất bộ cột chuẩn (template). Trước khi điền, hãy chốt danh sách thuộc tính mô tả mà mọi mục từ phải có. Một template tối thiểu nên gồm: Tên cột, Tên nghiệp vụ, Mô tả, Kiểu dữ liệu, Bắt buộc, Khóa, Giá trị hợp lệ, Ví dụ. Sự nhất quán này giúp người đọc quét nhanh.
Bước 4 — Điền từng mục từ. Đi qua từng cột của từng bảng. Với mỗi cột, đặc biệt chú trọng cột "Mô tả" và "Quy tắc nghiệp vụ" — đây là phần DBMS không tự sinh ra và là giá trị gia tăng thực sự của BA. Hãy hỏi: "Nếu một người hoàn toàn mới đọc dòng này, họ có hiểu cột này dùng để làm gì không?"
Bước 5 — Đối chiếu với người am hiểu nghiệp vụ. Đưa bản nháp cho SME (chuyên gia nghiệp vụ) và developer rà soát. Họ sẽ phát hiện những giá trị status bị thiếu, những quy tắc ngầm chưa được ghi. Đây là bước hay bị bỏ qua nhưng quan trọng nhất để tài liệu đúng.
Bước 6 — Đặt cơ chế duy trì. Một data dictionary lỗi thời còn nguy hiểm hơn không có, vì nó tạo niềm tin sai. Hãy gắn việc cập nhật data dictionary vào quy trình thay đổi schema: mỗi khi có migration thêm/sửa cột, tài liệu phải được cập nhật trong cùng pull request hoặc cùng ticket. Hãy ghi rõ phiên bản và ngày cập nhật cuối ở đầu tài liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ ghi tên cột và kiểu dữ liệu, bỏ trống cột mô tả. Đây là sai lầm phổ biến nhất. Một data dictionary chỉ có customer_name | VARCHAR(100) thì DBMS đã tự biết rồi, bạn chẳng thêm giá trị gì. Sức mạnh nằm ở cột mô tả nghiệp vụ và quy tắc.
Lỗi 2 — Để tài liệu lỗi thời. Schema thay đổi mà tài liệu đứng yên. Sau 6 tháng, không ai còn tin tài liệu nữa và nó chết. Mẹo: biến việc cập nhật thành điều kiện bắt buộc trong "definition of done" của mỗi thay đổi database.
Lỗi 3 — Mô tả vòng vo, lặp lại tên cột. Mô tả cột created_date là "ngày tạo" thì vô nghĩa. Hãy viết "Thời điểm bản ghi đơn hàng được tạo trong hệ thống, sinh tự động, dùng để tính SLA giao hàng". Mô tả phải thêm thông tin, không lặp lại cái đã hiển nhiên.
Lỗi 4 — Bỏ qua đơn vị và múi giờ. Cột amount là VND hay USD? Cột thời gian theo giờ Việt Nam hay UTC? Những thứ này phải ghi rõ trong data dictionary, nếu không sẽ gây lỗi tính toán nghiêm trọng.
Mẹo 1 — Dùng giá trị mẫu (sample value). Một ví dụ cụ thể đôi khi giải thích tốt hơn cả đoạn mô tả dài. Thấy 0123456789 người đọc hiểu ngay đây là chuỗi giữ số 0 đầu.
Mẹo 2 — Đánh dấu dữ liệu cá nhân/nhạy cảm. Thêm một cột phân loại (ví dụ: Công khai / Nội bộ / Nhạy cảm) giúp đội bảo mật và tuân thủ làm việc dễ hơn — đặc biệt quan trọng với dữ liệu cá nhân theo quy định bảo vệ dữ liệu.
Mẹo 3 — Liên kết tới ERD và tài liệu yêu cầu. Data dictionary không sống một mình. Hãy đặt liên kết hai chiều: từ mỗi bảng trong ERD trỏ tới trang dictionary tương ứng, và ngược lại.
Bài tập thực hành
Hãy chọn một hệ thống bạn quen thuộc — ví dụ một ứng dụng đặt lịch khám bệnh đơn giản — và thực hiện:
- Chọn một bảng trung tâm, ví dụ
appointments(lịch hẹn), với các cột giả định:appointment_id,patient_id,doctor_id,scheduled_at,status,fee,note,created_at.
- Tạo một data dictionary dạng bảng với các cột template: Tên cột, Tên nghiệp vụ, Mô tả, Kiểu dữ liệu, Bắt buộc, Khóa, Giá trị hợp lệ, Ví dụ.
- Điền đầy đủ 8 mục từ. Đặc biệt với cột
status, hãy tự định nghĩa ít nhất 5 giá trị hợp lệ (ví dụ: Đã đặt, Đã xác nhận, Hoàn thành, Bệnh nhân hủy, Bác sĩ hủy) kèm mô tả. Với cộtfee, ghi rõ đơn vị tiền tệ. Với cộtscheduled_at, ghi rõ múi giờ.
- Viết quy tắc nghiệp vụ cho ít nhất 3 cột. Ví dụ:
scheduled_atkhông được nằm trong quá khứ khi tạo mới;feekhông âm;patient_idvàdoctor_idlà FK trỏ tới bảng tương ứng.
- Tự kiểm tra: đưa tài liệu cho một người không biết hệ thống và xem họ có hiểu từng cột mà không cần hỏi thêm không. Nếu họ phải hỏi, đó là chỗ mô tả của bạn còn yếu.
Tóm tắt
Data Dictionary là tài liệu mô tả đầy đủ, có cấu trúc về mọi phần tử dữ liệu trong hệ thống — nó là phần "chú thích chi tiết" bổ trợ cho bức tranh tổng thể ERD. Mỗi mục từ tương ứng một attribute và nên gồm tên kỹ thuật, tên nghiệp vụ, mô tả, kiểu dữ liệu, ràng buộc, giá trị hợp lệ, khóa, quy tắc nghiệp vụ và ví dụ.
Giá trị thực sự của data dictionary, như ba tình huống ở trên cho thấy, không nằm ở những cột mà DBMS tự biết (kiểu dữ liệu), mà ở phần ý nghĩa nghiệp vụ mà chỉ con người mới ghi được: status nào nghĩa là gì, số tài khoản phải giữ số 0 đầu, tiền tính theo đơn vị nào. Đó chính là phần BA đóng góp.
Hãy nhớ ba nguyên tắc: viết cột mô tả cho ra hồn (đừng để trống, đừng lặp lại), giữ tài liệu luôn cập nhật (gắn vào quy trình thay đổi schema), và liên kết nó với ERD cùng tài liệu yêu cầu. Một data dictionary tốt giúp tiết kiệm hàng tuần onboard, ngăn sự cố dữ liệu tốn kém, và biến mô hình trừu tượng thành công cụ làm việc hằng ngày cho cả đội. Đây là một trong những deliverable thuyết phục và bền vững nhất mà một Business Analyst có thể tạo ra.