Tối ưu hóa mô hình dữ liệu: Nên dùng Explicit Measures hay Calculation Groups?

Tối ưu hóa mô hình dữ liệu: Nên dùng Explicit Measures hay Calculation Groups?

Với sự ra đời của các Hàm do người dùng định nghĩa (UDF - User Defined Functions) và sự kết hợp của chúng với Calculation Groups, cộng đồng công nghệ đang có nhiều tranh luận về việc liệu có nên tiếp tục tạo các Explicit Measures (đo lường tường minh) hay thay vào đó cung cấp Calculation Groups cho những người tạo báo cáo.

Cả hai tính năng này đều đóng vai trò thiết yếu khi đơn giản hóa một mô hình ngữ nghĩa (semantic model) thông qua việc mô đun hóa logic và giảm thiểu sự trùng lặp của logic nghiệp vụ. Tuy nhiên, câu hỏi đặt ra là: Cách tiếp cận nào mang lại sự linh hoạt và dễ sử dụng hơn cho người dùng?

So sánh mô hình dữ liệu

Vấn đề cốt lõi

UDF rất hữu ích để chuẩn hóa logic nghiệp vụ, đảm bảo logic đó chỉ xuất hiện một lần trên mỗi mô hình dữ liệu. Ngược lại, Calculation Groups hữu ích cho những người thiết kế báo cáo để áp dụng logic nghiệp vụ vào các measures. Một điểm khác biệt lớn là Calculation Groups hiển thị với người thiết kế báo cáo (Report Designers), trong khi UDF chỉ có thể sử dụng trong các biểu thức DAX và không thể sử dụng trực tiếp trên giao diện người dùng (Front-End).

Vấn đề chúng ta cần giải quyết là: Liệu chúng ta nên thêm các Explicit Measures hay chỉ cung cấp Calculation Groups cho người dùng? Ví dụ, khi cần tính toán giá trị của năm trước (Previous Year - PY), tôi có thể cung cấp một Calculation Item để người dùng sử dụng, hoặc tôi có thể thêm một Explicit Measure cho kết quả PY đó.

Góc nhìn của người dùng

Chúng ta cần xem xét hai nhóm người dùng chính:

• Người thiết kế báo cáo: Những người sử dụng các mô hình ngữ nghĩa của chúng ta và cần hiểu rõ mô hình đó.
• Người xem báo cáo: Những người cần hiểu những gì chúng ta hiển thị trong các hình ảnh trực quan mà không cần nhiều sự diễn giải.

Trực quan hóa dữ liệu

Sử dụng Matrix Visualizations

Khi xây dựng một Matrix (ma trận) chứa phân cấp lịch làm (Calendar hierarchy) và các Measures cho Online Sales, PY và PM, tôi đã thử nghiệm cả hai cách tiếp cận.

Với Calculation Items, tôi phải lọc các Calculation Items để loại bỏ các mục không cần thiết (ví dụ: PY (Week) sẽ gây lỗi khi dùng với Quarters và Months). Kết quả cho ra đúng như mong đợi. Tuy nhiên, khi sử dụng Explicit Measures, tôi nhận thấy kết quả là giống hệt nhau nhưng có một lợi thế lớn: Explicit Measures cho phép tôi sửa đổi tên hiển thị trong trực quan. Ví dụ, các Measures cho PY và PM có thể có tên khác nhau để dễ hiểu hơn. Điều này là không thể thực hiện với Calculation Items, vì các trực quan luôn hiển thị tên của Calculation Items và tôi không thể đổi tên chúng.

Các loại biểu đồ khác (Cột hoặc Thanh)

Tương tự như với Matrix, khi sử dụng biểu đồ cột, Calculation Items yêu cầu phải thêm bộ lọc và không thể đổi tên tên hiển thị. Trong khi đó, Explicit Measures cho phép đổi tên tự do.

Một vấn đề nhỏ với Calculation Items là tiêu đề và phụ đề thường chứa thông tin trùng lặp hoặc các thuật ngữ vô nghĩa như "Time Function" đối với người xem báo cáo, gây khó hiểu khi không được chỉnh sửa kỹ lưỡng.

Bảng Pivot trong Excel

Khi chuyển sang Excel Pivot Tables, Calculation Groups gặp một số vấn đề cụ thể. Cột PY có thể bị trống rỗng ngay cả khi có dữ liệu (ví dụ: năm 2022), ngay cả khi đã lọc đúng Calculation Items.

Excel Pivot Tables

Ngay cả khi sử dụng Explicit Measures, vấn đề về PY vẫn tồn tại nếu dùng time intelligence dựa trên lịch. Tuy nhiên, khi sử dụng PY measure với time intelligence cổ điển, nó hoạt động tốt. Điều này cho thấy một vấn đề tương tác giữa Excel và time intelligence dựa trên lịch. Dù vậy, Explicit Measures vẫn cho phép đổi tên measure, giống như trong Power BI.

Tác động đến BI tự phục vụ (Self-service BI)

Đối với người xem báo cáo, cả hai phương pháp đều tạo ra các báo cáo giống nhau. Tuy nhiên, đối với người thiết kế báo cáo, sự khác biệt là rõ rệt.

Người thiết kế phải biết cách sử dụng mô hình dữ liệu và Calculation Groups. Điều này tạo ra rào cản đối với Self-service BI, nơi các nhà phát triển cung cấp mô hình dữ liệu và người dùng tự tạo báo cáo của riêng họ. Nếu chỉ sử dụng Calculation Groups thay vì cung cấp Explicit Measures, việc đào tạo và tài liệu hướng dẫn là bắt buộc.

Chúng ta sẽ gặp hạn chế, ví dụ như khi cố gắng lọc dữ liệu theo một measure không tồn tại vì nó chỉ có sẵn dưới dạng Calculation item. Việc này trở nên khó khăn hơn nhiều so với việc "materialize" (hiện thực hóa) tất cả các measures cần thiết và đặt chúng vào các Display Folders có cấu trúc tốt. Người dùng có thể chỉ cần chọn các measures cần thiết và làm việc với chúng một cách trực quan.

Kết luận

Như đã thấy, việc tạo các Explicit Measures mang lại lợi ích lớn cho người thiết kế báo cáo làm việc với các mô hình ngữ nghĩa của chúng ta.

Nguyên tắc của tôi khi tạo các mô hình ngữ nghĩa là:

Nhu cầu của người dùng được đặt lên hàng đầu. Các lý do kỹ thuật luôn đứng sau. Không có lợi ích kỹ thuật nào quan trọng hơn khả năng sử dụng và tính dễ hiểu của đầu ra.

Việc lựa chọn giữa Explicit Measures và Calculation Groups không chỉ là vấn đề kỹ thuật, mà còn là vấn đề về trải nghiệm người dùng và hiệu quả làm việc.