Bài viết này giải thích chi tiết về các vấn đề liên quan đến thiết kế bảng Fact trong Data Warehouse dựa trên kiến thức chung từ các tài liệu và thực tiễn của các chuyên gia trong lĩnh vực này.

1. Bảng Fact là gì?

Bảng Fact (Fact Table) là thành phần trung tâm của mô hình Data Warehouse, nơi lưu trữ các dữ liệu định lượng (metrics) hoặc các sự kiện kinh doanh (business events) như doanh thu, số lượng bán hàng, chi phí, v.v. Bảng Fact thường được liên kết với các bảng Dimension (bảng chiều) thông qua các khóa ngoại (foreign keys) để cung cấp ngữ cảnh cho dữ liệu.

2. Các loại bảng Fact

Theo các chuyên gia như Ralph Kimball và Bill Inmon, có ba loại bảng Fact chính:

• Transactional Fact Table (Bảng Fact Giao dịch):
  • Lưu trữ dữ liệu ở mức chi tiết nhất, thường là từng giao dịch riêng lẻ (ví dụ: mỗi lần bán hàng).
  • Đặc điểm: Hạt (grain) nhỏ nhất, mỗi dòng đại diện cho một sự kiện cụ thể.
  • Ví dụ: Bảng lưu thông tin bán hàng với các cột như OrderID, ProductID, CustomerID, DateID, Quantity, Revenue.
• Periodic Snapshot Fact Table (Bảng Fact Ảnh chụp Định kỳ):
  • Lưu trữ dữ liệu tại một thời điểm cụ thể hoặc khoảng thời gian cố định (ví dụ: số dư tài khoản cuối ngày, doanh thu hàng tháng).
  • Đặc điểm: Dữ liệu được tổng hợp theo chu kỳ (ngày, tuần, tháng).
  • Ví dụ: Bảng lưu số liệu tồn kho cuối ngày với các cột như DateID, ProductID, WarehouseID, StockLevel.
• Accumulating Snapshot Fact Table (Bảng Fact Tích lũy):
  • Theo dõi tiến trình của một quy trình kinh doanh có nhiều giai đoạn (ví dụ: đơn hàng từ lúc đặt hàng đến giao hàng).
  • Đặc điểm: Các cột ngày (date) được cập nhật khi quy trình tiến triển.
  • Ví dụ: Bảng theo dõi đơn hàng với các cột như OrderID, OrderDate, ShipDate, DeliveryDate, TotalCost.

3. Cách thiết kế bảng Fact

Thiết kế bảng Fact đòi hỏi sự chú ý đến các yếu tố sau:

• Xác định Grain (Mức độ chi tiết):
  • Grain là mức độ chi tiết của dữ liệu trong bảng Fact. Ví dụ: “Mỗi giao dịch bán hàng” hay “Tổng doanh thu hàng ngày theo sản phẩm”.
  • Grain phải được định nghĩa rõ ràng trước khi thiết kế để tránh nhầm lẫn.
• Chọn các Measure (Đo lường):
  • Đây là các cột số trong bảng Fact (ví dụ: Quantity, Revenue, Cost).
  • Measure có thể là additive (cộng được, như doanh thu), semi-additive (cộng được trong một số trường hợp, như số dư tài khoản), hoặc non-additive (không cộng được, như tỷ lệ phần trăm).
• Liên kết với bảng Dimension:
  • Mỗi bảng Fact cần các khóa ngoại (foreign keys) để tham chiếu đến bảng Dimension (như ProductID, DateID, CustomerID).
  • Các khóa này tạo nên mô hình sao (Star Schema) hoặc mô hình bông tuyết (Snowflake Schema).
• Xử lý dữ liệu lớn:
  • Partitioning (phân vùng) theo thời gian hoặc theo chiều (dimension) để tối ưu hóa truy vấn.
  • Indexing trên các khóa ngoại để tăng tốc độ truy xuất.

4. Các khóa liên quan

• Khóa chính (Primary Key):
  • Trong một số trường hợp, bảng Fact không cần khóa chính rõ ràng mà dùng tổ hợp các khóa ngoại làm khóa duy nhất (degenerate dimension).
  • Ví dụ: OrderID trong Transactional Fact Table có thể đóng vai trò là degenerate dimension.
• Khóa ngoại (Foreign Key):
  • Liên kết bảng Fact với bảng Dimension, đảm bảo tính toàn vẹn dữ liệu.
  • Ví dụ: DateID tham chiếu đến bảng Dim_Date, ProductID tham chiếu đến bảng Dim_Product.
• Surrogate Key:
  • Đôi khi được thêm vào để tăng hiệu suất hoặc đơn giản hóa truy vấn, đặc biệt trong các hệ thống phức tạp. Ví dụ như một đơn hàng có nhiều Item và bạn sẽ gặp lặp lại nhiều lần cho OrderID và để duy nhất, bạn nên thêm vào Surrogate Key để hệ thống Index theo khoá này, và tốc độ truy xuất dữ liệu nhanh hơn. Hoặc bảng Fact được tổng hợp từ nhiều nguồn dữ liệu khác nhau, và có khả năng trùng lắp về OrderID, giải pháp là ta thêm vào Surrogate Key để đảm bảo không bao giờ gặp trùng lắp dữ liệu.

5. Các vấn đề thường gặp khi thiết kế bảng Fact

Dựa trên tài liệu của các chuyên gia và thực tiễn, dưới đây là một số vấn đề phổ biến:

• Grain không rõ ràng:
  • Nếu Grain không được định nghĩa chính xác, bảng Fact có thể chứa dữ liệu không đồng nhất, dẫn đến kết quả phân tích sai lệch.
  • Giải pháp: Xác định Grain ngay từ đầu và kiểm tra tính nhất quán.
• Hiệu suất kém:
  • Bảng Fact thường chứa hàng tỷ dòng dữ liệu, nếu không phân vùng hoặc tối ưu hóa index, truy vấn sẽ rất chậm.
  • Giải pháp: Sử dụng kỹ thuật partitioning, indexing, và materialized views.
• Dữ liệu trùng lặp:
  • Thiết kế khóa không tốt có thể dẫn đến việc ghi đè hoặc trùng lặp dữ liệu.
  • Giải pháp: Kiểm tra tính duy nhất của dữ liệu đầu vào và sử dụng ETL (Extract, Transform, Load) để làm sạch.
• Measure không phù hợp:
  • Chọn sai loại Measure (ví dụ: coi số dư tài khoản là additive) dẫn đến tổng hợp sai.
  • Giải pháp: Phân loại rõ ràng additive, semi-additive, non-additive khi thiết kế.
• Quá nhiều Dimension:
  • Liên kết quá nhiều bảng Dimension làm bảng Fact phức tạp và khó bảo trì.
  • Giải pháp: Giới hạn số Dimension cần thiết hoặc sử dụng Snowflake Schema khi phù hợp.

6. Quan điểm cá nhân từ góc nhìn chuyên gia

Các quan điểm thiết kế bảng Fact trong các tài liệu:

• Kimball nhấn mạnh tính đơn giản và hiệu quả với Star Schema, ưu tiên Grain (mức độ chi tiết) rõ ràng và Measure additive.
• Inmon tập trung vào tính toàn vẹn dữ liệu và thường khuyến nghị cách tiếp cận chuẩn hóa hơn, phù hợp với các hệ thống doanh nghiệp lớn.
• Vấn đề lớn nhất tôi thấy là sự đánh đổi giữa hiệu suất và tính linh hoạt: Star Schema nhanh nhưng kém linh hoạt, trong khi Snowflake Schema tiết kiệm không gian nhưng phức tạp hơn.