Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 48 — Glossary và Data Dictionary

ECBA Certification Preparation Bài 48/60

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa gia nhập một dự án ngân hàng số. Trong cuộc họp đầu tiên, bộ phận kinh doanh nói về "khách hàng đang hoạt động", đội kỹ thuật gọi đó là "active user", còn bộ phận tuân thủ lại định nghĩa "khách hàng" là người đã hoàn tất eKYC. Ba người, ba cách hiểu, và cùng một từ. Kết quả? Một báo cáo đếm sai số lượng khách hàng, một quyết định kinh doanh dựa trên số liệu lệch lạc, và hàng giờ tranh cãi không hồi kết.

Đây chính xác là vấn đề mà hai công cụ trong bài học hôm nay được sinh ra để giải quyết: Glossary (Bảng thuật ngữ) và Data Dictionary (Từ điển dữ liệu). Trong BABOK Guide v3, cả hai đều là techniques (kỹ thuật) thuộc nhóm hỗ trợ giao tiếp và quản lý thông tin. Với kỳ thi ECBA, bạn cần phân biệt rõ chúng — vì đề thi rất thích đặt câu hỏi kiểu "khi nào dùng Glossary, khi nào dùng Data Dictionary" hoặc "công cụ nào định nghĩa thuật ngữ nghiệp vụ, công cụ nào mô tả phần tử dữ liệu".

Quan trọng hơn cả việc thi, đây là kỹ năng nền tảng của một Business Analyst (BA) chuyên nghiệp. Một BA giỏi không chỉ thu thập yêu cầu — họ tạo ra một ngôn ngữ chung để cả tổ chức nói cùng một thứ tiếng. Glossary và Data Dictionary chính là hai cuốn từ điển của ngôn ngữ chung đó.

Khái niệm cốt lõi

Glossary — Bảng thuật ngữ nghiệp vụ

Glossary là tập hợp các thuật ngữ nghiệp vụ (business terms) cùng với định nghĩa của chúng, được sử dụng trong một lĩnh vực, một dự án hoặc một tổ chức cụ thể. Mục tiêu duy nhất và quan trọng nhất của Glossary là đảm bảo mọi người hiểu giống nhau về cùng một từ ngữ.

Theo BABOK, một mục (entry) trong Glossary thường gồm:

  • Term — bản thân thuật ngữ (ví dụ: "Khách hàng VIP").
  • Definition — định nghĩa rõ ràng, đầy đủ, không mơ hồ.
  • Synonyms / Aliases — các tên gọi khác cho cùng khái niệm (ví dụ "khách hàng ưu tiên", "premium customer").
  • Related terms — các thuật ngữ liên quan để tham chiếu chéo.
  • Đôi khi có thêm: nguồn định nghĩa, người phụ trách (owner), ngày cập nhật.
Điểm mấu chốt để nhớ cho kỳ thi: Glossary nói về Ý NGHĨA của khái niệm nghiệp vụ, không phải về cách dữ liệu được lưu trữ. Khi bạn định nghĩa "đơn hàng đã hoàn tất nghĩa là gì", bạn đang làm Glossary.

Khi nào cần Glossary?

Glossary đặc biệt có giá trị khi:

  • Lĩnh vực nghiệp vụ phức tạp — ngân hàng, bảo hiểm, y tế, logistics, nơi có hàng trăm thuật ngữ chuyên ngành như "dư nợ", "phí phạt trả chậm", "hạn mức tín dụng tuần hoàn".
  • Nhiều bên liên quan đến từ các phòng ban khác nhau — mỗi phòng ban thường có "phương ngữ" riêng cho cùng một khái niệm.
  • Dự án có người nước ngoài hoặc đội offshore — thuật ngữ tiếng Việt và tiếng Anh cần được ánh xạ chính xác.
  • Người mới gia nhập liên tục — Glossary giúp họ "nhập môn" nhanh.

Data Dictionary — Từ điển dữ liệu

Data Dictionary mô tả chi tiết về các phần tử dữ liệu (data elements) được sử dụng trong giải pháp — tức là nó nói về dữ liệu, không phải về khái niệm nghiệp vụ trừu tượng.

Theo BABOK, một Data Dictionary mô tả hai loại đối tượng:

  • Primitive data elements (phần tử dữ liệu cơ bản) — các trường dữ liệu đơn lẻ. Mỗi phần tử thường có:
- Name — tên trường (ví dụ: customer_email). - Aliases — tên gọi khác. - Values / Meanings — tập giá trị hợp lệ và ý nghĩa (ví dụ: status = A → Active, I → Inactive). - Description — mô tả. - Data type / Format — kiểu dữ liệu (số, chuỗi, ngày...) và định dạng. - Length / Size — độ dài tối đa. - Allowable values / Validation rules — quy tắc kiểm tra hợp lệ.

  • Composite data elements (phần tử dữ liệu phức hợp) — được tạo từ nhiều phần tử cơ bản, mô tả bằng các ký hiệu cấu trúc:
- Sequence — các phần tử xuất hiện theo thứ tự (ví dụ: Họ và tên = Họ + Tên đệm + Tên). - Repetition — một phần tử lặp lại nhiều lần (ví dụ: Đơn hàng = tập hợp nhiều Dòng sản phẩm). - Optional — phần tử có thể có hoặc không (ví dụ: Địa chỉ phụ là tùy chọn).

Điểm mấu chốt cho kỳ thi: Data Dictionary nói về CẤU TRÚC và THUỘC TÍNH KỸ THUẬT của dữ liệu. Khi bạn xác định "trường số điện thoại có tối đa 11 ký tự, chỉ chứa chữ số", bạn đang làm Data Dictionary.

Phân biệt nhanh Glossary vs Data Dictionary

Tiêu chíGlossaryData Dictionary
Đối tượng mô tảKhái niệm/thuật ngữ nghiệp vụPhần tử dữ liệu
Câu hỏi trả lời"Từ này nghĩa là gì?""Dữ liệu này được lưu thế nào?"
Người dùng chínhMọi bên liên quan nghiệp vụBA, dev, tester, DBA
Ví dụ nội dung"Khách hàng VIP = khách có doanh số > 500 triệu/năm""customer_tier: string, 3 ký tự, giá trị {STD, GLD, VIP}"
Tập trung vàoÝ nghĩaCấu trúc, định dạng, ràng buộc
Một cách nhớ đơn giản: Glossary cho NGƯỜI nghiệp vụ đọc, Data Dictionary cho người LÀM VIỆC VỚI DỮ LIỆU đọc. Hai công cụ bổ sung cho nhau chứ không thay thế nhau.

Tình huống thực tế

Tình huống 1: Ngân hàng số Timo và từ "khách hàng hoạt động"

Một fintech ngân hàng số giả định tên Timo Digital triển khai hệ thống báo cáo. Khi xây dashboard "Số khách hàng hoạt động", ba phòng ban đưa ra ba định nghĩa khác nhau:

  • Marketing: khách hàng có đăng nhập app trong 30 ngày gần nhất.
  • Vận hành: khách hàng có ít nhất một giao dịch trong tháng.
  • Tài chính: khách hàng có số dư > 0.
Kết quả là cùng một dashboard nhưng ba phòng đọc ra ba con số: 120.000, 85.000 và 200.000. Cuộc họp ban điều hành bế tắc vì không ai tin số liệu.

BA vào cuộc, xây một Glossary và chốt định nghĩa: "Khách hàng hoạt động (Active Customer) = khách hàng có ít nhất một giao dịch tài chính thành công trong 30 ngày gần nhất. Đồng nghĩa: active user. Khác với: registered customer (đã đăng ký nhưng chưa giao dịch)." Định nghĩa này được ký duyệt bởi cả ba trưởng phòng và đưa vào Glossary chung.

Bài học: Glossary không phải tài liệu kỹ thuật — nó là một thỏa thuận chính trị - nghiệp vụ. Giá trị lớn nhất nằm ở quá trình thương lượng để đạt được MỘT định nghĩa duy nhất được mọi người công nhận.

Tình huống 2: Sàn TMĐT và trường "trạng thái đơn hàng"

Một sàn thương mại điện tử kiểu Tiki/Shopee giả định triển khai tích hợp với đối tác giao vận. Đội backend Việt Nam và đội đối tác (offshore Ấn Độ) liên tục bug vì trường order_status. Phía Việt Nam dùng giá trị "Đang giao", phía đối tác hiểu "Shipping", và hệ thống lưu mã 3 — không ai biết 3 nghĩa là gì.

BA xây một Data Dictionary cho trường này:

Element: order_status
Type: Integer (mã trạng thái)
Allowable values:
  1 = Created (Đơn mới tạo)
  2 = Confirmed (Đã xác nhận)
  3 = Shipping (Đang giao)
  4 = Delivered (Đã giao thành công)
  5 = Cancelled (Đã hủy)
Validation: bắt buộc, chỉ nhận giá trị 1–5
Default: 1

Sau khi tài liệu này được chia sẻ, số lỗi tích hợp liên quan đến trạng thái đơn hàng giảm rõ rệt vì cả hai đội tham chiếu cùng một bảng giá trị chuẩn.

Bài học: Data Dictionary loại bỏ sự mơ hồ ở tầng dữ liệu. Đặc biệt khi tích hợp giữa các hệ thống/đội nhóm, việc chốt tập giá trị hợp lệ và ý nghĩa của từng mã quan trọng không kém việc viết code.

Tình huống 3: Dự án bảo hiểm và sự bổ trợ của cả hai công cụ

Một công ty bảo hiểm như Bảo Việt (giả định bối cảnh) làm dự án số hóa hợp đồng. Thuật ngữ "thời gian chờ" (waiting period) gây tranh cãi: người dùng nghĩ là thời gian chờ duyệt hồ sơ, nhưng nghiệp vụ bảo hiểm định nghĩa đó là khoảng thời gian sau khi ký hợp đồng mà quyền lợi chưa có hiệu lực.

BA xử lý ở hai tầng:

  • Trong Glossary: định nghĩa rõ "Thời gian chờ = khoảng thời gian (tính bằng ngày) kể từ ngày hiệu lực hợp đồng mà trong đó người được bảo hiểm chưa được hưởng quyền lợi cho bệnh/sự kiện liên quan."
  • Trong Data Dictionary: mô tả trường waiting_period_days — kiểu Integer, đơn vị ngày, giá trị từ 0 đến 365, mặc định 30.
Bài học: Glossary và Data Dictionary không cạnh tranh — chúng làm việc theo cặp. Glossary giải quyết "khái niệm này nghĩa là gì", Data Dictionary giải quyết "khái niệm này được lưu trữ và ràng buộc ra sao". Một BA thành thạo biết khi nào cần một, khi nào cần cả hai.

Hướng dẫn từng bước

Dưới đây là quy trình thực tế để xây dựng và duy trì hai công cụ này:

Bước 1 — Thu thập thuật ngữ từ nguồn thực. Đừng ngồi nghĩ ra thuật ngữ. Hãy rút chúng ra từ các cuộc phỏng vấn, tài liệu yêu cầu, biên bản họp, email. Mỗi khi một từ gây tranh cãi hoặc được hỏi đi hỏi lại "ý anh là gì", đó là ứng viên cho Glossary.

Bước 2 — Xác định mức độ ưu tiên. Không cần định nghĩa mọi từ. Tập trung vào: (a) từ có nhiều cách hiểu, (b) từ chuyên ngành đặc thù, (c) từ then chốt cho phạm vi dự án.

Bước 3 — Viết định nghĩa rõ ràng. Một định nghĩa tốt phải: không dùng chính từ đó để định nghĩa nó (tránh vòng tròn), có thể đo lường/kiểm chứng được khi có thể, và được viết bằng ngôn ngữ mà người nghiệp vụ hiểu.

Bước 4 — Lấy sự đồng thuận (validation). Đây là bước quan trọng nhất với Glossary. Đưa định nghĩa cho các bên liên quan duyệt. Một định nghĩa không được công nhận thì vô giá trị.

Bước 5 — Với dữ liệu, lập Data Dictionary song song. Khi một thuật ngữ nghiệp vụ trở thành một trường dữ liệu cụ thể, hãy ghi lại name, type, format, length, allowable values, validation rules. Phân biệt rõ phần tử primitive và composite.

Bước 6 — Chỉ định owner và lưu tại nơi tập trung. Cả hai tài liệu phải có người phụ trách (thường là BA) và được đặt ở nơi cả nhóm truy cập được (Confluence, SharePoint, wiki nội bộ), không nằm rải rác trong email.

Bước 7 — Duy trì như tài liệu sống. Cập nhật khi thuật ngữ thay đổi, đánh dấu phiên bản, ghi ngày sửa. Glossary và Data Dictionary lỗi thời còn nguy hiểm hơn không có, vì người ta tin vào nó.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhầm lẫn Glossary với Data Dictionary trong bài thi. Đây là cái bẫy ECBA kinh điển. Nhớ: nếu câu hỏi nói về thuật ngữ nghiệp vụ, ý nghĩa, sự hiểu chung → Glossary. Nếu nói về phần tử dữ liệu, kiểu dữ liệu, định dạng, giá trị hợp lệ → Data Dictionary.

Lỗi 2 — Định nghĩa vòng tròn. Viết "Khách hàng VIP là khách hàng quan trọng" không giúp ai. Phải cụ thể, đo được: "khách hàng có doanh số mua > 500 triệu VND/năm".

Lỗi 3 — Coi Glossary là việc làm một lần rồi quên. Thuật ngữ nghiệp vụ thay đổi theo thời gian. Glossary phải là living document, được rà soát định kỳ.

Lỗi 4 — Bỏ qua đồng nghĩa và bí danh. Nếu không ghi rõ "active user" = "khách hàng hoạt động", người đọc tài liệu tiếng Anh và tiếng Việt vẫn hiểu lệch nhau.

Lỗi 5 — Nhồi quá nhiều thuật ngữ. Glossary 500 mục mà không ai đọc thì vô dụng. Chất lượng và sự đồng thuận quan trọng hơn số lượng.

Mẹo nhớ cho thi: Glossary = "Giải nghĩa từ ngữ cho con người". Data Dictionary = "Dữ liệu — cấu trúc và định dạng". Và nhớ ba ký hiệu cấu trúc của composite element: Sequence (thứ tự), Repetition (lặp lại), Optional (tùy chọn).

Bài tập thực hành

Bài 1 — Phân loại. Với mỗi mục sau, xác định nó thuộc Glossary hay Data Dictionary: (a) "Đơn hàng tồn đọng = đơn chưa giao sau 7 ngày kể từ ngày đặt." (b) "phone_number: string, 10–11 ký tự, chỉ chứa chữ số, bắt đầu bằng 0." (c) "Khách hàng tiềm năng là người đã để lại số điện thoại nhưng chưa mua." (d) "gender: char(1), giá trị {M, F, O}."

Bài 2 — Viết định nghĩa. Chọn một lĩnh vực bạn quen (ví dụ: quán cà phê, lớp học, shop online) và viết 5 mục Glossary, mỗi mục có Term, Definition và ít nhất một Synonym.

Bài 3 — Lập Data Dictionary. Cho thực thể "Sinh viên", hãy lập Data Dictionary cho ít nhất 4 trường (ví dụ: mã sinh viên, họ tên, ngày sinh, trạng thái học tập), ghi đủ name, type, format, length, allowable values.

Bài 4 — Composite element. Mô tả trường "Địa chỉ giao hàng" như một composite data element, sử dụng đúng các khái niệm Sequence, Optional, Repetition (gợi ý: số nhà + đường + phường + quận + thành phố, trong đó địa chỉ phụ là Optional).

Đáp án gợi ý bài 1: (a) Glossary, (b) Data Dictionary, (c) Glossary, (d) Data Dictionary.

Tóm tắt

  • Glossary là tập hợp các thuật ngữ nghiệp vụ và định nghĩa của chúng, nhằm tạo ra ngôn ngữ chung và sự hiểu thống nhất giữa các bên liên quan. Nó trả lời câu hỏi "Từ này nghĩa là gì?".
  • Data Dictionary mô tả chi tiết các phần tử dữ liệu — name, type, format, length, allowable values, validation — gồm phần tử primitivecomposite (với ba ký hiệu Sequence, Repetition, Optional). Nó trả lời câu hỏi "Dữ liệu này được lưu trữ và ràng buộc thế nào?".
  • Hai công cụ bổ trợ nhau: Glossary cho người nghiệp vụ, Data Dictionary cho người làm việc với dữ liệu. Trong nhiều dự án phức tạp (ngân hàng, bảo hiểm, TMĐT), bạn cần cả hai.
  • Giá trị thật của Glossary nằm ở sự đồng thuận — một định nghĩa được mọi người công nhận. Giá trị của Data Dictionary nằm ở sự chính xác — loại bỏ mơ hồ ở tầng dữ liệu, đặc biệt khi tích hợp hệ thống.
  • Cả hai phải là tài liệu sống, có owner, lưu tập trung, cập nhật thường xuyên.
Với kỳ thi ECBA, hãy thuộc lòng ranh giới giữa hai khái niệm này — đó là loại câu hỏi gần như chắc chắn xuất hiện. Còn trong nghề, hãy biến việc xây Glossary và Data Dictionary thành thói quen ngay từ ngày đầu dự án: một ngôn ngữ chung tốt sẽ tiết kiệm cho bạn hàng chục giờ tranh cãi về sau.