Tài liệu sẽ giải thích chi tiết về việc thiết kế bảng Dimension (bảng Dim) trong Data Warehouse dựa trên các tài liệu và thực tiễn của các chuyên gia như Ralph Kimball, Bill Inmon và các nguồn phổ biến khác trong lĩnh vực này.

1. Bảng Dimension là gì?

Bảng Dimension (bảng Dim) chứa các thông tin mô tả (descriptive attributes) cung cấp ngữ cảnh cho dữ liệu trong bảng Fact. Ví dụ: thông tin về sản phẩm, khách hàng, thời gian, địa điểm, v.v. Chúng thường được liên kết với bảng Fact thông qua các khóa (keys) để hỗ trợ phân tích đa chiều.

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

Dựa trên tài liệu của các chuyên gia, có nhiều loại bảng Dimension phổ biến:

• Conformed Dimension (Dimension Chuẩn hóa):
  • Được sử dụng chung giữa nhiều bảng Fact trong Data Warehouse.
  • Đặc điểm: Đảm bảo tính nhất quán trong toàn hệ thống.
  • Ví dụ: Bảng Dim_Date chứa thông tin ngày/tháng/năm, dùng cho cả bảng Fact bán hàng và bảng Fact tồn kho.
• Junk Dimension (Dimension Rác):
  • Kết hợp các thuộc tính nhỏ, ít quan trọng hoặc ít thay đổi (low-cardinality attributes) thành một bảng để giảm số lượng Dimension.
  • Đặc điểm: Tiết kiệm không gian và đơn giản hóa mô hình.
  • Ví dụ: Bảng Dim_Junk chứa các cờ (flag) như IsActive, IsShipped thay vì tạo bảng riêng.
• Degenerate Dimension (Dimension Thoái hóa, Suy biến):
  • Không phải bảng Dimension riêng biệt mà là một thuộc tính trong bảng Fact, thường là khóa tự nhiên từ nguồn (source system).
  • Đặc điểm: Không cần bảng Dim riêng, lưu trực tiếp trong Fact.
  • Ví dụ: OrderID trong bảng Fact bán hàng.
  • Để dịch Degenerate Dimension ra tiếng Việt cho đúng nghĩa, chắc phải tìm cách dịch cho đúng, đây là cách dịch theo lối nói chuyện thông thường
• Role-Playing Dimension (Dimension theo vai trò):
  • Một bảng Dimension được sử dụng nhiều lần trong các vai trò khác nhau bằng cách tạo các view hoặc alias.
  • Đặc điểm: Tiết kiệm không gian, tái sử dụng.
  • Ví dụ: Bảng Dim_Date được dùng cho OrderDate, ShipDate, DeliveryDate trong bảng Fact.
• Slowly Changing Dimension (SCD – Dimension Thay đổi Chậm):
  • Xử lý các thay đổi của dữ liệu theo thời gian. Có các loại chính:
    • SCD Type 1: Ghi đè dữ liệu cũ (không lưu lịch sử).
    • SCD Type 2: Thêm dòng mới với phiên bản mới, giữ lịch sử (dùng cột như StartDate, EndDate, IsCurrent).
    • SCD Type 3: Thêm cột để lưu giá trị cũ (giới hạn lịch sử).
  • Ví dụ: Bảng Dim_Customer thay đổi địa chỉ khách hàng theo thời gian.
• Mini-Dimension:
  • Tách các thuộc tính thay đổi nhanh (high-cardinality) ra thành bảng riêng để giảm kích thước bảng Dim chính.
  • Ví dụ: Tách thông tin nhân khẩu học (tuổi, thu nhập) khỏi Dim_Customer thành Dim_Demographics.

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

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

• Xác định các thuộc tính (Attributes):
  • Lựa chọn các thuộc tính mô tả có ý nghĩa kinh doanh (ví dụ: ProductName, Category, Price trong Dim_Product).
  • Tránh đưa các số liệu định lượng (metrics) vào bảng Dim, vì chúng thuộc về bảng Fact.
• Chuẩn hóa hay Phi chuẩn hóa:
  • Star Schema: Phi chuẩn hóa (denormalized) để tăng tốc độ truy vấn, chấp nhận dư thừa dữ liệu.
  • Snowflake Schema: Chuẩn hóa (normalized) thành nhiều bảng liên quan để tiết kiệm không gian, nhưng phức tạp hơn.
• Xử lý Slowly Changing Dimension (SCD):
  • Quyết định cách xử lý thay đổi (Type 1, 2, 3) dựa trên yêu cầu kinh doanh.
  • Ví dụ: Nếu cần lịch sử, dùng SCD Type 2 với các cột StartDate, EndDate.
• Tối ưu hóa hiệu suất:
  • Giới hạn số lượng cột và dòng trong bảng Dim.
  • Sử dụng indexing trên khóa chính hoặc các cột thường xuyên truy vấn.

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

• Surrogate Key (Khóa thay thế):
  • Là khóa chính (primary key) của bảng Dim, thường là số nguyên tăng dần, không mang ý nghĩa kinh doanh.
  • Ví dụ: ProductSK trong Dim_Product.
  • Lợi ích: Đảm bảo tính duy nhất, tách biệt với khóa tự nhiên từ nguồn, dễ tích hợp dữ liệu.
• Natural Key (Khóa tự nhiên):
  • Là khóa từ hệ thống nguồn, được lưu kèm để truy xuất ngược hoặc đối chiếu.
  • Ví dụ: ProductCode từ hệ thống ERP trong Dim_Product.
• Foreign Key (Khóa ngoại):
  • Trong mô hình Snowflake Schema, các bảng Dim con có thể liên kết với nhau qua khóa ngoại.
  • Ví dụ: CategoryID trong Dim_Product tham chiếu đến Dim_Category.

Ví dụ bảng Dim với Surrogate Key:

Bảng Dim_Product:

ProductSK (Surrogate Key)	ProductCode (Natural Key)	ProductName	Category	Price
1	P001	Laptop X	Electronics	1000.00
2	P002	Mouse Y	Accessories	20.00

• ProductSK là Surrogate Key, liên kết với bảng Fact.
• ProductCode là Natural Key từ nguồn.

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

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

• Quá nhiều thuộc tính:
  • Bảng Dim chứa quá nhiều cột làm chậm truy vấn và khó bảo trì.
  • Giải pháp: Tách thành Mini-Dimension hoặc Junk Dimension nếu cần.
• Xử lý SCD không nhất quán:
  • Chọn sai loại SCD (ví dụ: dùng Type 1 khi cần lịch sử) dẫn đến mất dữ liệu hoặc không đáp ứng yêu cầu phân tích.
  • Giải pháp: Xác định rõ yêu cầu kinh doanh trước khi thiết kế.
• Dư thừa dữ liệu không cần thiết:
  • Phi chuẩn hóa quá mức trong Star Schema gây lãng phí không gian.
  • Giải pháp: Cân nhắc Snowflake Schema nếu dung lượng là vấn đề lớn.
• Hiệu suất kém:
  • Bảng Dim quá lớn (hàng triệu dòng) mà không có index hoặc partition làm chậm join với bảng Fact.
  • Giải pháp: Tối ưu hóa index trên Surrogate Key và các cột lọc phổ biến.
• Không đồng bộ giữa các nguồn:
  • Khi tích hợp dữ liệu từ nhiều nguồn, Natural Key có thể xung đột.
  • Giải pháp: Dùng Surrogate Key và ánh xạ (mapping) dữ liệu nguồn.

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

• Kimball: Ủng hộ Star Schema với bảng Dim phi chuẩn hóa, Surrogate Key, và SCD Type 2 để đơn giản và hiệu quả.
• Inmon: Thiên về chuẩn hóa (Snowflake Schema), tập trung vào tính toàn vẹn dữ liệu và khả năng mở rộng cho hệ thống lớn.
• Vấn đề tôi thấy: Sự đánh đổi giữa tốc độ (Star Schema) và tiết kiệm không gian (Snowflake Schema) luôn là thách thức. Ngoài ra, việc xử lý SCD Type 2 thường phức tạp hơn trong thực tế khi dữ liệu nguồn không đáng tin cậy.

Nếu bạn cần ví dụ cụ thể hơn (như mã SQL) hoặc muốn đào sâu vào một loại Dimension cụ thể, hãy cho tôi biết!