Khái niệm data modeling hiện đại

Data modeling (mô hình hóa dữ liệu) là việc mô tả có cấu trúc các khái niệm nghiệp vụ và cách chúng được lưu trữ, trước khi viết dòng code hay tạo bảng đầu tiên. Mục tiêu của data modeling không phải là tạo thêm thủ tục, mà là tạo ra hợp đồng dữ liệu (schema, DDL — Data Definition Language, data contract) và đóng góp vào kho metadata chung để nghiệp vụ và kỹ thuật hiểu dữ liệu giống nhau. Một nguyên tắc đáng nhớ từ tài liệu Hackolade, phỏng theo George Box: mọi mô hình đều không hoàn hảo — giá trị của mô hình nằm ở tính hữu dụng, không phải sự hoàn mỹ.

Ba tầng mô hình: conceptual, logical, physical

Tầng	Trả lời câu hỏi	Nội dung
Conceptual	Nghiệp vụ nói về cái gì?	Các thực thể nghiệp vụ lớn và quan hệ giữa chúng; mức trừu tượng cao nhất, dùng để thống nhất từ vựng chung
Logical	Dữ liệu gồm những gì?	Entity, attribute, kiểu dữ liệu, quan hệ — vẫn độc lập công nghệ, chưa nói tới database cụ thể
Physical	Lưu như thế nào?	Cài đặt cho một công nghệ đích cụ thể: index, partition, định dạng lưu trữ, quy ước đặt tên

Cách chia ba tầng giúp mỗi đối tượng tham gia đúng tầng của mình: lãnh đạo và BA (Business Analyst) làm việc ở conceptual, data architect ở logical, DBA (Database Administrator) và data engineer ở physical.

Vì sao NoSQL cần cách mô hình hóa khác

Công cụ ERD (Entity-Relationship Diagram) truyền thống sinh ra cho thế giới relational: dữ liệu chuẩn hóa (normalized), bảng phẳng, quan hệ qua khóa ngoại. Database NoSQL — nhất là loại document như MongoDB — hoạt động theo triết lý khác:

• Nested object: một document có thể chứa object và mảng lồng nhau nhiều tầng. “Đơn hàng” chứa luôn mảng “dòng hàng” bên trong, thay vì tách ra bảng riêng.
• Denormalization: dữ liệu được chủ động lặp lại để đọc nhanh — chấp nhận dư thừa có kiểm soát, ngược với chuẩn hóa của relational.
• Thiết kế theo access pattern: với relational, bạn mô hình theo cấu trúc dữ liệu rồi viết query sau; với NoSQL, bạn xuất phát từ câu hỏi ứng dụng sẽ hỏi (query-driven) rồi thiết kế cấu trúc phục vụ đúng các truy vấn đó.

Ba đặc điểm này khiến sơ đồ ERD phẳng không đủ để mô tả. Hackolade giải quyết bằng cách chọn JSON Schema làm xương sống biểu diễn: mọi cấu trúc — kể cả bảng relational — được mô tả bằng JSON Schema, vốn sinh ra để diễn đạt object lồng nhau, mảng, kiểu phức hợp. Trên giao diện, bạn nhìn thấy đồng thời ERD và cây schema phân cấp của từng entity.

Polyglot model: định nghĩa một lần, sinh nhiều target

Từ phiên bản 5.2.0, Hackolade Studio đưa ra Polyglot data model: một mô hình logic trung lập công nghệ, dùng thuật ngữ tổng quát (entity, attribute) và tập kiểu dữ liệu là hợp nhất của mọi công nghệ đích. Polyglot model là bản gốc (master); từ nó bạn derive ra physical model cho từng target — mỗi model đích tự động dùng đúng thuật ngữ (table/collection/node/vertex) và kiểu dữ liệu của công nghệ đó. Khi Polyglot model thay đổi, các model đích cập nhật theo kèm hộp thoại phân tích tác động.

Một điểm thú vị trong triết lý của Hackolade: bạn có thể denormalize ngay trong Polyglot model (thiết kế theo access pattern), rồi khi derive sang target relational, công cụ normalize lại on-the-fly — ngược với lối cũ “chuẩn hóa trước, phi chuẩn hóa sau”.

Metadata-as-Code: model là file JSON trong Git

Model của Hackolade được lưu ở định dạng JSON (JavaScript Object Notation) không độc quyền, nên có thể đặt ngay cạnh source code trong Git repository. Cách tiếp cận Metadata-as-Code này mang lại:

• Versioning và review: mọi thay đổi mô hình đi qua branch, commit, peer review — như code. Bản Workgroup tích hợp Git ngay trong ứng dụng.
• Tự động hóa qua CLI (Command-Line Interface): forward/reverse engineering, so sánh model, sinh script ALTER, xuất tài liệu — chạy được trong pipeline CI/CD (Continuous Integration/Continuous Deployment).
• Một nguồn sự thật: cùng một file model vừa sinh schema kỹ thuật cho database/API, vừa đẩy data dictionary sang công cụ governance cho phía nghiệp vụ.

Use case: ngân hàng đa nền tảng

Hình dung một ngân hàng tại Việt Nam: core banking chạy Oracle, còn kênh số (mobile app, internet banking) dùng MongoDB để phục vụ hồ sơ khách hàng dạng document, đọc nhanh theo từng phiên đăng nhập. Không có mô hình chung, “khách hàng” ở core và “khách hàng” ở kênh số dần lệch nhau: khác kiểu dữ liệu ngày sinh, khác quy ước mã chi nhánh, khác danh mục loại giấy tờ.

Với Hackolade, đội data architect định nghĩa entity Khách hàng một lần trong Polyglot model — đầy đủ attribute, kiểu dữ liệu, mô tả nghiệp vụ. Từ đó derive ra hai physical model: bảng chuẩn hóa cho Oracle và collection có nested object cho MongoDB (ví dụ mảng giay_to_tuy_than nằm ngay trong document khách hàng). Khi quy định yêu cầu thêm trường mới, chỉ cần sửa Polyglot model; hai model đích nhận thay đổi qua impact analysis, sinh script ALTER cho Oracle và cập nhật schema validation cho MongoDB. File model nằm trong Git nên kiểm toán truy được ai đổi gì, khi nào.

Bài tiếp theo

Bắt tay thực hành với Bắt đầu nhanh.

Nguồn tham khảo

• Data modeling
• Polyglot Data Modeling
• Metadata-as-Code
• Welcome to Hackolade Studio

BSD Insight là đối tác triển khai Hackolade tại Việt Nam — liên hệ tư vấn.