Mô hình dữ liệu chủ: định nghĩa thực thể và thuộc tính

Trước khi gộp được “Nguyễn Văn A” từ ba hệ thống thành một bản ghi vàng, cả tổ chức phải thống nhất một chuyện tưởng đơn giản: “khách hàng” gồm những trường gì? Trường nào là bắt buộc, trường nào dùng để nhận diện, và một khách hàng liên quan thế nào tới đơn hàng hay địa chỉ? Câu trả lời cho những câu hỏi đó chính là mô hình dữ liệu chủ (master data model) — bản thiết kế nền cho mọi việc còn lại trong MDM. Trang này giải thích mô hình dữ liệu chủ là gì, vì sao phải mô hình hóa trước khi gộp, và Ataccama ONE MDM làm việc này theo hướng low-code ra sao.

Mô hình dữ liệu chủ là gì?

Mô hình dữ liệu chủ là cách doanh nghiệp định nghĩa các thực thể cốt lõi cùng cấu trúc của chúng trong hệ thống MDM. Nó trả lời ba câu hỏi nền tảng:

Có những thực thể nào? — ví dụ Khách hàng, Sản phẩm, Nhà cung cấp, Nhân viên, Địa điểm.
Mỗi thực thể gồm những thuộc tính nào? — ví dụ Khách hàng có tên, mã số thuế, số điện thoại, email, ngày sinh; Sản phẩm có mã SKU, tên, đơn vị tính, nhóm hàng.
Các thực thể liên hệ với nhau ra sao? — ví dụ một Khách hàng có nhiều Địa chỉ; một Đơn hàng thuộc về một Khách hàng và gồm nhiều Sản phẩm.

Có thể coi mô hình dữ liệu chủ như bản thiết kế (blueprint) của ngôi nhà dữ liệu: nó vẽ ra “phòng nào là phòng nào, mỗi phòng có gì, các phòng nối với nhau thế nào” trước khi bạn bắt đầu xây. Ba thành phần cần nắm:

Thực thể (entity)

Là đối tượng nghiệp vụ cốt lõi mà ta muốn quản lý như dữ liệu chủ: Khách hàng, Sản phẩm, Nhà cung cấp… Mỗi thực thể về sau sẽ có những bản ghi vàng tương ứng.

Thuộc tính (attribute)

Là các trường mô tả một thực thể. Với Khách hàng cá nhân có thể là họ tên, ngày sinh, số CCCD, điện thoại, email; với Khách hàng doanh nghiệp là tên công ty, mã số thuế, ngành nghề. Khi mô hình hóa, người ta thường chỉ rõ thêm: trường nào bắt buộc, trường nào dùng để nhận diện/đối sánh, trường nào có định dạng chuẩn (ví dụ email phải đúng định dạng).

Quan hệ (relationship)

Là mối liên kết giữa các thực thể: Khách hàng — Địa chỉ, Khách hàng — Đơn hàng, Sản phẩm — Nhóm hàng. Quan hệ cho phép mô tả cả những cấu trúc phức tạp như hộ gia đình (household) hay cây công ty mẹ – con, vốn rất quan trọng trong nhiều bài toán dữ liệu chủ.

Vì sao phải mô hình hóa trước khi gộp?

Đây là điểm mấu chốt với người mới. Đối sánh và gộp không thể chạy đúng nếu trước đó cả tổ chức chưa thống nhất “khách hàng gồm những trường gì”. Lý do:

Phải biết so trường nào với trường nào. Đối sánh nhận ra hai bản ghi cùng một người bằng cách so các trường như tên, điện thoại, mã số thuế. Nếu mô hình không định nghĩa rõ những trường đó (và trường nào dùng để nhận diện), thì máy không biết lấy gì ra để so.
Phải có “khung” chung cho mọi nguồn. Mỗi hệ thống đặt tên trường mỗi kiểu — CRM gọi phone, kế toán gọi dien_thoai, website gọi mobile. Mô hình dữ liệu chủ đóng vai trò khung thống nhất để mọi nguồn ánh xạ (map) về cùng một bộ thuộc tính chuẩn. Không có khung đó, không thể hợp nhất.
Quy tắc sống sót cần biết cấu trúc. Để quyết định “giữ giá trị nào khi mâu thuẫn”, quy tắc sống sót phải áp trên từng thuộc tính cụ thể đã được định nghĩa. Mô hình chính là nơi liệt kê các thuộc tính đó.
Tránh “gộp nhầm phạm vi”. Nếu không thống nhất Khách hàng cá nhân và Khách hàng doanh nghiệp là hai thực thể (hay hai biến thể) khác nhau, rất dễ gộp lẫn hai loại không nên gộp.

Nói ngắn gọn: mô hình là bản thiết kế, đối sánh – gộp – sống sót là thi công. Thi công mà không có thiết kế thì mỗi đội làm một kiểu, kết quả lệch nhau.

Ataccama ONE MDM mô hình hóa thế nào (low-code)?

Điểm dễ chịu của Ataccama ONE MDM là mô hình hóa theo hướng low-code: thay vì viết nhiều mã, người dùng định nghĩa thực thể, thuộc tính và quan hệ ngay trên giao diện, theo cách gần với ngôn ngữ nghiệp vụ. Một số ý chính (diễn giải ở mức khái niệm):

Khai báo thực thể và thuộc tính trực quan. Bạn mô tả “Khách hàng gồm các trường này”, “Sản phẩm gồm các trường kia” mà không phải dựng thủ công từng bảng cơ sở dữ liệu phía dưới.
Khai báo quan hệ giữa các thực thể để dựng được phân cấp và liên kết (Khách hàng — Địa chỉ, công ty mẹ — công ty con…).
Gắn liền với chất lượng dữ liệu. Vì Ataccama ONE dùng chung nền metadata, các luật chất lượng dữ liệu (định dạng email, chuẩn hóa số điện thoại…) có thể áp ngay trên thuộc tính của mô hình, để dữ liệu vào MDM đã sạch.
Là nền cho đối sánh – gộp. Sau khi có mô hình, ta cấu hình luật đối sánh trên các thuộc tính nhận diện và quy tắc sống sót trên từng thuộc tính — tất cả đứng trên cùng một mô hình.

Cách tiếp cận low-code giúp bộ phận nghiệp vụ tham gia được vào việc định nghĩa “khách hàng là gì”, thay vì giao trọn cho lập trình viên — điều rất quan trọng vì người hiểu nghiệp vụ mới biết trường nào thực sự cần.

Liên hệ với thuật ngữ nghiệp vụ (business glossary)

Mô hình dữ liệu chủ định nghĩa cấu trúc kỹ thuật (“Khách hàng có các trường này”). Nhưng “khách hàng” nghĩa là gì theo ngôn ngữ nghiệp vụ — đã ký hợp đồng mới tính, hay cứ để lại thông tin là tính? — lại thuộc về thuật ngữ nghiệp vụ (business glossary).

Hai thứ này bổ trợ cho nhau và nên đi cùng:

Business glossary định nghĩa ý nghĩa thuật ngữ (“khách hàng đang hoạt động” là gì) để cả công ty hiểu giống nhau.
Mô hình dữ liệu chủ hiện thực hóa ý nghĩa đó thành thực thể + thuộc tính cụ thể trong MDM.

Khi liên kết mô hình với glossary, bản ghi vàng vừa đúng cấu trúc vừa đúng nghĩa nghiệp vụ — nền tảng để cả tổ chức tin và dùng chung, đúng tinh thần data governance.

Ví dụ Việt Nam: mô hình thực thể “Khách hàng”

Một công ty phân phối muốn quản lý khách hàng làm dữ liệu chủ. Họ mô hình hóa như sau:

Thực thể: Khách hàng, với hai biến thể cá nhân và doanh nghiệp.
Thuộc tính của khách hàng cá nhân: họ tên (bắt buộc), số CCCD (nhận diện), số điện thoại (nhận diện), email, ngày sinh.
Thuộc tính của khách hàng doanh nghiệp: tên công ty (bắt buộc), mã số thuế (nhận diện), ngành nghề, người liên hệ.
Quan hệ: một Khách hàng có nhiều Địa chỉ; nhiều Khách hàng doanh nghiệp có thể thuộc cùng một tập đoàn mẹ (quan hệ mẹ – con).

Nhờ mô hình này, khi dữ liệu từ CRM, kế toán và website chảy vào, hệ thống biết: trường mã số thuế dùng để nhận diện khách doanh nghiệp, số điện thoại dùng để nhận diện khách cá nhân, và một khách có thể có nhiều địa chỉ. Đối sánh – gộp – sống sót sau đó đều đứng trên bản thiết kế này, nên kết quả nhất quán thay vì mỗi đội hiểu một kiểu.

'Bản ghi vàng' (golden record) là gì Thành phẩm mà mô hình dữ liệu chủ hướng tới: phiên bản dữ liệu đáng tin duy nhất.

Đối sánh và nhận diện trùng lặp (matching) Bước chạy ngay sau mô hình hóa — so các thuộc tính nhận diện để nhóm bản ghi.

Thuật ngữ nghiệp vụ (business glossary) Định nghĩa ý nghĩa nghiệp vụ của thuật ngữ, đi cùng mô hình dữ liệu chủ.