Thiết kế mô hình dữ liệu

Sau khi tạo model đầu tiên ở bài trước, bài này đi vào các kỹ thuật thiết kế chính trong Hackolade Studio: entity và attribute, quan hệ trong ERD (Entity-Relationship Diagram), cấu trúc lồng nhau cho document database, tư duy denormalization theo access pattern, và Polyglot model để thiết kế một lần dùng cho nhiều công nghệ.

Entity và attribute theo target

Mỗi model gắn với một target technology, và bộ kiểu dữ liệu bạn được chọn bám sát target đó: model PostgreSQL cho bạn các kiểu của PostgreSQL, model MongoDB cho bạn các kiểu BSON. Nhờ vậy, thứ bạn thiết kế chính là thứ chạy được thật, không phải mô hình “chung chung” rồi phải phiên dịch lại bằng tay.

Ngoài kiểu vô hướng (string, number, date…), Hackolade hỗ trợ kiểu phức hợp chứa cấu trúc con: object (chứa các attribute con), array (danh sách các phần tử cùng schema) và tuple (dãy phần tử có thứ tự, mỗi phần tử có thể khác schema). Tên gọi cụ thể thay đổi theo target — map, struct, list… — nhưng ý tưởng là một: attribute có thể chứa cả một cấu trúc bên trong.

Quan hệ trong ERD

Với database quan hệ, quan hệ giữa hai bảng thể hiện qua khóa ngoại (foreign key). Trong Hackolade, cách trực quan nhất để tạo quan hệ là kéo attribute phía con thả lên attribute phía cha có kiểu dữ liệu tương thích ngay trong ERD; ngoài ra còn có menu, nút trên toolbar và menu chuột phải. Sau khi tạo, bạn chỉnh trong Properties pane: entity và attribute phía tham chiếu, tên quan hệ, cardinality (một-nhiều, một-một…). Với database quan hệ, khóa ngoại ghép (compound key) gồm nhiều attribute mỗi bên cũng được hỗ trợ.

Hackolade phân biệt hai loại quan hệ:

Foreign key — quan hệ khóa ngoại thông thường, được đưa vào script khi forward engineering.
Foreign master — đánh dấu “nguồn chuẩn” của một field bị nhân bản do denormalization. Loại này chỉ để tài liệu hóa, không bao giờ sinh ra ràng buộc trong database.

Quan hệ được quản lý ở cấp model (không theo từng container), nên bạn vẽ được quan hệ xuyên schema ở các target hỗ trợ điều đó.

Cấu trúc lồng nhau — thế mạnh với document database

Tool ERD truyền thống sinh ra cho thế giới bảng phẳng. Document database như MongoDB lại lưu dữ liệu dạng JSON (JavaScript Object Notation) lồng nhau nhiều tầng — và đây là chỗ Hackolade khác biệt: bạn thêm object hoặc array vào entity bằng chuột phải ngay trong hộp entity trên ERD (hoặc trong tab schema view của entity), rồi tiếp tục lồng sâu tùy ý. Trong khi bạn thiết kế, tab JSON Preview liên tục sinh JSON Schema và document dữ liệu mẫu tương ứng — rất tiện để đối chiếu với dữ liệu thật.

Denormalization và thiết kế theo access pattern

Với database quan hệ, ta chuẩn hóa (normalization) để tránh trùng lặp dữ liệu. Với document database, nguyên tắc lại là: dữ liệu hay được đọc cùng nhau thì nên nằm cùng một document — nhúng (embed) thay vì tách bảng rồi join. Truy vấn nhanh hơn, nhưng đổi lại dữ liệu bị nhân bản và việc giữ nhất quán chuyển từ database sang tầng ứng dụng (MongoDB từ v3.2 có $lookup để join, nhưng nhúng vẫn là pattern chủ đạo).

Vì vậy thiết kế cho document database xuất phát từ access pattern — ứng dụng sẽ truy vấn gì, màn hình nào cần dữ liệu nào — chứ không từ dạng chuẩn. Hackolade cho bạn vừa nhúng dữ liệu, vừa dùng quan hệ Foreign master để ghi lại field nào là bản sao của nguồn nào — sau này cần cập nhật đồng loạt còn biết đường lần.

Ví dụ: khách hàng và đơn hàng của chuỗi bán lẻ

Một chuỗi bán lẻ tại Việt Nam cần lưu khách hàng và đơn hàng. Cùng một thiết kế logic, hai target cho ra hai hình hài khác nhau.

Dạng chuẩn hóa trên PostgreSQL — hai bảng, nối bằng khóa ngoại:

CREATE TABLE khach_hang (
  ma_kh        VARCHAR(10) PRIMARY KEY,
  ho_ten       VARCHAR(100) NOT NULL,
  dien_thoai   VARCHAR(15),
  dia_chi      VARCHAR(255),
  phuong_xa    VARCHAR(100),
  tinh_thanh   VARCHAR(100)
);

CREATE TABLE don_hang (
  ma_dh        VARCHAR(12) PRIMARY KEY,
  ma_kh        VARCHAR(10) NOT NULL REFERENCES khach_hang (ma_kh),
  ngay_dat     DATE NOT NULL,
  tong_tien    NUMERIC(15,0)
);

Dạng document nhúng trên MongoDB — đơn hàng mang sẵn thông tin khách để đọc một lần là đủ:

{
  "maDonHang": "DH-2026-0815",
  "ngayDat": "2026-07-28",
  "tongTien": 1850000,
  "khachHang": {
    "maKH": "KH00123",
    "hoTen": "Nguyễn Văn An",
    "dienThoai": "0901234567",
    "diaChi": {
      "duong": "12 Lê Lợi",
      "phuongXa": "Phường Bến Thành",
      "tinhThanh": "TP. Hồ Chí Minh"
    }
  },
  "chiTiet": [
    { "maSP": "SP-101", "tenSP": "Áo thun", "soLuong": 2, "donGia": 250000 },
    { "maSP": "SP-205", "tenSP": "Quần jean", "soLuong": 1, "donGia": 1350000 }
  ]
}

Ở bản MongoDB, khachHang là object nhúng và chiTiet là array các object — đúng loại cấu trúc mà Hackolade mô hình hóa trực tiếp trên ERD, còn quan hệ Foreign master ghi nhận rằng dữ liệu khách nhúng trong đơn hàng có nguồn chuẩn ở collection khách hàng.

Polyglot model — thiết kế một lần, ánh xạ nhiều target

Nếu tổ chức của bạn dùng đồng thời nhiều công nghệ (ví dụ PostgreSQL cho giao dịch, MongoDB cho ứng dụng, Avro cho luồng sự kiện), Hackolade có Polyglot Data Model: một model trung lập công nghệ, vẫn cho phép kiểu phức hợp lồng nhau và cả thiết kế denormalized theo access pattern.

Từ Polyglot model, bạn derive (dẫn xuất) ra model vật lý cho từng target. Khi derive, Hackolade tự ánh xạ kiểu dữ liệu sang kiểu bản địa của target, áp quy tắc biến đổi tên theo chuẩn từng công nghệ (nơi ưa camelCase, nơi không chấp nhận chữ hoa), và cho phép chọn lọc entity nào đưa vào target nào. Đáng chú ý: cấu trúc lồng nhau trong Polyglot model được tự động chuẩn hóa thành các bảng phẳng khi derive sang database quan hệ, còn derive sang NoSQL thì giữ nguyên dạng phân cấp. Model dẫn xuất vẫn chỉnh tiếp được độc lập (thêm index, partition… đặc thù target).

Với ví dụ bán lẻ ở trên, thay vì vẽ hai model tay, bạn có thể vẽ một Polyglot model rồi derive ra cả bản PostgreSQL lẫn bản MongoDB — hai schema luôn cùng một gốc định nghĩa.

Bài tiếp theo

Reverse engineering

Nguồn tham khảo

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