Relationships in Power BI, DAX Measures
6/18/2025•2分で読める
Relationships in Power BI, DAX Measures
Mô hình quan hệ (relationship model) là trái tim của bất kỳ báo cáo Power BI nào. Một mô hình được thiết kế tốt sẽ giúp các DAX measures hoạt động trơn tru, cho kết quả chính xác và hiệu suất tối ưu. Ngược lại, những sai sót trong relationship có thể dẫn đến kết quả sai lệch, lỗi tính toán và trải nghiệm người dùng tồi tệ.
Trong bài viết này, chúng ta sẽ "mổ xẻ" một sơ đồ quan hệ tuyển dụng (hình ảnh bạn cung cấp) để chỉ ra các lỗi tiềm ẩn thường gặp và phân tích sâu hơn về ảnh hưởng của chúng đến việc viết measures, đặc biệt khi liên quan đến các cột ngày tháng như CreateDate, EndDate, Day, Month.
Tổng Quan Sơ Đồ Quan Hệ (Dựa trên hình ảnh):
Chúng ta có các bảng chính:
Dimension Tables : Dim_Date, Dim_Job, Dim_RecruitingSeason.
Fact Tables: Application, Hired, Interviews, PhoneScreening.
Các Lỗi Relationship Tiềm Ẩn và Ảnh Hưởng Đến DAX Measures:
1. Vấn Đề Về Relationship Không Hoạt Động (Inactive Relationships) Với Dim_Date
Quan sát:
Bảng Dim_Date có nhiều mối quan hệ đến các bảng fact (Application, Hired, Interviews, PhoneScreening) thông qua các cột ngày khác nhau (ví dụ: Application[ApplyDate], Application[Created], Application[HiredDate], Hired[Created], Hired[EndDate], Interviews[Created], Interviews[Date]).
Trong số này, chỉ CÓ MỘT relationship từ Dim_Date đến mỗi bảng fact có thể ở trạng thái "Active" (nét liền). Các relationship còn lại sẽ "Inactive" (nét đứt). Ví dụ, Dim_Date[Date] có thể đang active với Application[ApplyDate] nhưng inactive với Application[Created].
Ảnh hưởng đến Measures:
Tính toán sai ngày: Nếu bạn viết một measure để đếm số lượng Application và đặt Dim_Date[Month] vào slicer, theo mặc định, Power BI sẽ sử dụng relationship active (ví dụ, Application[ApplyDate]) để lọc. Nếu bạn muốn đếm theo Application[Created], measure sẽ cho kết quả sai.
Lỗi logic khi dùng Day, Month: Khi bạn sử dụng các cột như Dim_Date[Day] hay Dim_Date[Month] trong visuals hoặc filters, chúng chỉ hoạt động dựa trên relationship active. Ví dụ, nếu bạn muốn xem số ứng viên được tuyển (Hired) theo Hired[EndDate] (ngày kết thúc hợp đồng/thử việc) và Dim_Date đang active với Hired[Created], việc lọc theo Dim_Date[Month] sẽ không cho kết quả theo EndDate.
Khó khăn khi tạo measures liên quan đến khoảng thời gian: Ví dụ, tính "Thời gian để Tuyển dụng" (Hired[Created] - Application[ApplyDate]). Nếu cả hai cột này đều cần được liên kết với Dim_Date cho các mục đích phân tích khác nhau, một trong hai relationship sẽ inactive, đòi hỏi USERELATIONSHIP khi cần.
2. Mối Quan Hệ Nhiều-Nhiều (Many-to-Many) Giữa Application và Hired
Quan sát: Đường nối giữa Application và Hired có ký hiệu * ở cả hai đầu, cho thấy một mối quan hệ nhiều-nhiều. Điều này có thể xảy ra nếu một ứng viên (ApplicantID) có nhiều đơn ứng tuyển (Application) và cũng có thể được ghi nhận "tuyển" nhiều lần (ví dụ: tái tuyển dụng, hoặc một ứng viên được tuyển cho nhiều vị trí từ các đơn ứng tuyển khác nhau).
Ảnh hưởng đến Measures:
Kết quả mơ hồ và nhân đôi (Ambiguity & Double Counting): Khi bạn cố gắng tổng hợp dữ liệu từ cả hai bảng, ví dụ, đếm số ứng viên được tuyển cho một JobCode cụ thể từ bảng Application, kết quả có thể bị nhân lên không chính xác nếu không có cơ chế phân giải rõ ràng (ví dụ: bảng bắc cầu hoặc logic DAX phức tạp).
Khó khăn khi lọc chéo: Việc lọc từ Application sang Hired (hoặc ngược lại) có thể không hoạt động như mong đợi hoặc tạo ra các bộ lọc không trực quan.
Hiệu suất kém: Relationship nhiều-nhiều thường kém hiệu quả hơn relationship một-nhiều.
Tác động lên CreateDate, EndDate: Nếu bạn muốn phân tích số lượng Hired records có CreateDate trong một tháng cụ thể, và đồng thời muốn lọc theo thông tin từ bảng Application (ví dụ, Application[Source]), relationship nhiều-nhiều có thể làm phức tạp việc đảm bảo ngữ cảnh lọc đúng.
3. Thiếu Rõ Ràng Trong Luồng Lọc Giữa Các Bảng Fact
Quan sát: Có các relationship giữa các bảng fact (ví dụ: Application tới Interviews, Application tới PhoneScreening). Chúng có thể dựa trên ApplicantID hoặc ApplicationID. Hướng lọc (filter direction) của các relationship này rất quan trọng.
Ảnh hưởng đến Measures:
Lọc một chiều (Single Direction): Nếu relationship là một chiều từ Application (phía "một") đến Interviews (phía "nhiều"), thì việc lọc trên Application sẽ lọc Interviews. Tuy nhiên, lọc trên Interviews (ví dụ, theo Interviews[Date]) sẽ không tự động lọc Application trừ khi bạn dùng CROSSFILTER hoặc relationship hai chiều.
Lỗi logic khi kết hợp ngày: Giả sử bạn muốn đếm số Application có ApplyDate trong tháng 1 VÀ có Interviews[Date] cũng trong tháng 1. Nếu không có luồng lọc đúng hoặc logic DAX phù hợp, bạn có thể không nhận được kết quả mong muốn.
Sử dụng CreateDate, EndDate từ nhiều bảng fact: Nếu bạn cần một measure tổng hợp dựa trên Application[Created], Interviews[Date], và Hired[EndDate], việc đảm bảo tất cả các bộ lọc ngày từ Dim_Date (thông qua USERELATIONSHIP khi cần) và các bộ lọc giữa các bảng fact được áp dụng đúng cách là một thách thức.
4. Sử Dụng StartDate và EndDate từ Dim_RecruitingSeason
Quan sát: Dim_RecruitingSeason có StartDate và EndDate. Bảng này liên kết với Dim_Job, và Dim_Job liên kết với Application.
Ảnh hưởng đến Measures:
Phân tích "trong kỳ tuyển dụng": Nếu bạn muốn đếm số Application có ApplyDate nằm trong khoảng StartDate và EndDate của một RecruitingSeason cụ thể, bạn sẽ cần logic DAX phức tạp hơn là một relationship đơn giản.
Applications In Season =
CALCULATE(
COUNTROWS(Application),
FILTER(
Application,
VAR AppDate = Application[ApplyDate]
VAR SeasonStartDate = RELATED(Dim_RecruitingSeason[StartDate]) // Giả sử có thể RELATED tới đây
VAR SeasonEndDate = RELATED(Dim_RecruitingSeason[EndDate])
RETURN AppDate >= SeasonStartDate && AppDate <= SeasonEndDate
)
)
Điều này yêu cầu đường dẫn RELATED phải rõ ràng và hoạt động. Nếu Dim_RecruitingSeason không trực tiếp liên kết với Application mà qua nhiều bảng, việc lấy StartDate/EndDate của season có thể phức tạp hơn.
Xung đột với Dim_Date: Nếu người dùng chọn một tháng từ Dim_Date và đồng thời chọn một RecruitingSeason, measure cần phải xử lý logic để ưu tiên bộ lọc nào hoặc kết hợp chúng một cách hợp lý.
Giải Pháp và Thực Hành Tốt Nhất:
Ưu tiên Star Schema: Cố gắng xây dựng mô hình hình sao với các bảng Dim rõ ràng và bảng Fact trung tâm. Giảm thiểu relationship trực tiếp giữa các bảng Fact.
Sử dụng USERELATIONSHIP một cách có ý thức: Đối với các kịch bản "role-playing dimension" (như Dim_Date với nhiều cột ngày), hãy tạo các measures riêng biệt sử dụng USERELATIONSHIP để kích hoạt relationship cần thiết.
Xử lý Relationship Nhiều-Nhiều:
Nếu có thể, hãy giới thiệu một bảng bắc cầu (bridge table) để chuyển thành hai relationship một-nhiều.
Nếu bắt buộc phải dùng relationship nhiều-nhiều trực tiếp, hãy hiểu rõ giới hạn và sử dụng các hàm DAX như CROSSFILTER cẩn thận, đồng thời kiểm tra kỹ lưỡng hiệu suất và tính chính xác.
Kiểm tra Hướng Lọc (Cross-Filter Direction): Mặc định là "Single". Chỉ sử dụng "Both" (hai chiều) khi thực sự cần thiết và hiểu rõ hậu quả về hiệu suất và khả năng gây mơ hồ.
Tạo Bảng Ngày (Dim_Date) Chuẩn: Đảm bảo bảng Dim_Date của bạn đầy đủ và được đánh dấu là "date table".
Đơn Giản Hóa Logic Ngày: Thay vì có nhiều cột ngày trong một bảng fact, nếu logic nghiệp vụ cho phép, xem xét việc chuẩn hóa hoặc tạo thêm các bảng fact/dim chuyên biệt nếu các sự kiện ngày đó thực sự khác biệt.
Kết Luận:
Mô hình quan hệ trong Power BI không chỉ là việc "kéo thả" các đường nối. Nó đòi hỏi sự hiểu biết sâu sắc về dữ liệu và cách các bảng tương tác với nhau. Các lỗi như relationship inactive không được xử lý, relationship nhiều-nhiều không đúng cách, hoặc luồng lọc không rõ ràng sẽ trực tiếp ảnh hưởng đến độ chính xác của các DAX measures, đặc biệt là những measure liên quan đến phân tích theo CreateDate, EndDate, Day, và Month. Bằng cách chú ý đến những chi tiết này và áp dụng các thực hành tốt nhất, bạn có thể xây dựng một nền tảng vững chắc cho các báo cáo Power BI mạnh mẽ và đáng tin cậy.
