Semantic model Power BI là gì? Cách dùng trong công việc thực tế
Semantic model (mô hình ngữ nghĩa) trong Power BI là lớp dữ liệu đã được mô hình hoá, gồm bảng, quan hệ giữa các bảng, công thức tính chỉ số và quy tắc phân quyền, nằm giữa nguồn dữ liệu và báo cáo. Trước đây Microsoft gọi nó là dataset.
Power BI là công cụ trực quan hoá dữ liệu và business intelligence [1], nhưng độ tin cậy của báo cáo phụ thuộc vào phần mô hình phía sau. Hiểu lầm phổ biến là coi semantic model chỉ là "dataset đổi tên" hoặc nhầm nó với file .pbix. Thực tế, một semantic model có thể phục vụ nhiều báo cáo cùng lúc, và đó là lý do nó đáng để bạn hiểu kỹ.
Mục lục
I. Semantic model Power BI là gì?
Khi bạn kéo cột "Doanh thu" vào một biểu đồ, con số đó không đến thẳng từ database. Nó đi qua semantic model: nơi định nghĩa doanh thu là gì, tính theo công thức nào, lọc theo bảng ngày nào, và ai được phép nhìn thấy dòng dữ liệu nào.
Nói gọn, semantic model là phần "hiểu nghiệp vụ" của Power BI. Báo cáo chỉ là lớp hiển thị. Nếu hai báo cáo cùng kết nối vào một semantic model, chúng sẽ cho ra cùng một con số cho cùng một chỉ số. Đó là điều mà việc mỗi người tự viết công thức trong file riêng khó đảm bảo.
1. Vì sao dataset được đổi tên thành semantic model?
Microsoft đổi tên vì "dataset" nghe giống một khối dữ liệu thô, trong khi thứ bạn thực sự xây là một mô hình có quan hệ, công thức và quy tắc phân quyền. Khi Power BI nằm trong hệ sinh thái Microsoft Fabric, cùng một workspace chứa nhiều loại item liên quan đến dữ liệu, và tên "semantic model" giúp phân biệt rõ phần mô hình hoá với phần lưu trữ.
Việc đổi tên ảnh hưởng đến bạn ở ba chỗ. Giao diện và tài liệu hiện gọi là semantic model. Một số API, script hoặc bài hướng dẫn cũ vẫn dùng chữ dataset, nên khi đọc code bạn sẽ gặp cả hai cách gọi. Còn với XMLA endpoint (cổng cho phép công cụ bên ngoài đọc và chỉnh sửa mô hình), cách làm việc với mô hình không thay đổi chỉ vì tên mới.
Về thời điểm đổi tên chính xác, bạn nên đối chiếu trực tiếp trên Microsoft Learn thay vì dựa vào bài viết bất kỳ, kể cả bài này.
II. Đặc điểm của một semantic model
Một semantic model được định hình bởi hai thứ: nó chứa những thành phần nào, và dữ liệu của nó được lưu trữ theo chế độ nào.
1. Thành phần: bảng, quan hệ, measure DAX, hierarchy, RLS
Mỗi thành phần gắn với một việc bạn làm hằng ngày:
Bảng (table): chứa dữ liệu đã qua Power Query. Việc của bạn là giữ lại cột cần dùng và đặt đúng kiểu dữ liệu.
Quan hệ (relationship): nối bảng fact với bảng dimension, thường theo kiểu một-nhiều. Quan hệ sai là nguyên nhân quen thuộc của số liệu không khớp.
Measure: phép tính được định nghĩa một lần bằng DAX (Data Analysis Expressions, ngôn ngữ công thức của Power BI) rồi dùng lại ở mọi visual. Doanh thu, biên lợi nhuận, tỷ lệ tăng trưởng nên nằm ở đây.
Hierarchy: chuỗi cấp bậc như Năm, Quý, Tháng hoặc Vùng, Tỉnh, Cửa hàng. Người dùng khoan sâu (drill down) mà không cần bạn dựng lại từng biểu đồ.
RLS (row-level security, phân quyền theo dòng dữ liệu): mỗi người chỉ thấy phần dữ liệu thuộc phạm vi của mình, ví dụ trưởng vùng miền Nam không thấy số của miền Bắc.
2. Import, DirectQuery và Direct Lake: chọn chế độ nào?
Chế độ lưu trữ quyết định dữ liệu nằm ở đâu và truy vấn nhanh hay chậm. Bảng dưới đây tóm tắt để bạn chọn nhanh.
Chế độ | Dữ liệu nằm ở đâu | Phù hợp khi | Cần lưu ý |
|---|---|---|---|
Import | Nạp vào bộ nhớ của semantic model | Báo cáo quản trị, dữ liệu cập nhật theo lịch (hằng ngày, hằng giờ) | Phải đặt lịch refresh, dữ liệu chỉ mới đến lần refresh gần nhất |
DirectQuery | Vẫn nằm ở nguồn, truy vấn mỗi lần mở visual | Cần dữ liệu gần thời gian thực, hoặc dữ liệu quá lớn để nạp | Tốc độ phụ thuộc nguồn, một số tính năng DAX bị giới hạn |
Direct Lake | Đọc trực tiếp từ bảng Delta trong OneLake | Đã dùng Microsoft Fabric, muốn tốc độ gần Import mà không nạp lại dữ liệu | Chỉ có trong Fabric, cần chuẩn bị dữ liệu ở dạng bảng Delta |
Nếu chưa chắc, bạn bắt đầu bằng Import. Chế độ này đơn giản nhất, hỗ trợ đầy đủ DAX và thường cho trải nghiệm mượt. Chỉ chuyển sang DirectQuery khi có lý do cụ thể như yêu cầu dữ liệu tức thời hoặc khối lượng quá lớn. Direct Lake đáng cân nhắc khi tổ chức bạn đã có Fabric và dữ liệu đã nằm sẵn trong OneLake.
III. Ví dụ thực tế: semantic model cho báo cáo bán hàng
Giả sử bạn là analyst của một công ty bán lẻ. Dữ liệu nằm trong SQL Server với các bảng Sales (giao dịch), Product, Customer, Region và Date. Tên bảng dưới đây chỉ để minh hoạ, bạn thay bằng bảng của mình.
Bước đầu là kéo dữ liệu vào Power BI Desktop và làm sạch trong Power Query: bỏ cột không dùng, chuẩn hoá kiểu dữ liệu, đặt tên cột dễ hiểu. Bước tiếp theo là dựng star schema (lược đồ hình sao): bảng Sales ở giữa, các bảng dimension xung quanh, quan hệ một-nhiều từ dimension sang Sales. Đừng quên đánh dấu bảng Date là date table để các hàm thời gian chạy đúng.
Sau đó bạn viết measure. Ba measure dưới đây là bộ khung cho hầu hết báo cáo bán hàng:
Total Sales = SUM ( Sales[SalesAmount] )
Sales LY =
CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
Sales YoY % =
DIVIDE ( [Total Sales] - [Sales LY], [Sales LY] )Với RLS, bạn tạo một role và gắn bộ lọc lên bảng Region, ví dụ 'Region'[ManagerEmail] = USERPRINCIPALNAME(), để mỗi trưởng vùng chỉ thấy số của vùng mình. Cuối cùng, bạn publish lên workspace trên Power BI Service, đặt lịch refresh và gán người dùng vào role RLS.
Điểm đáng chú ý là báo cáo không còn là nơi chứa logic. Đồng nghiệp muốn một dashboard khác chỉ cần kết nối vào semantic model đã publish và kéo các measure có sẵn, không phải tự viết lại công thức doanh thu.
IV. Ứng dụng semantic model trong công việc hằng ngày
1. Dùng chung một nguồn số liệu
Khi mỗi báo cáo tự nạp dữ liệu và tự viết công thức, một thay đổi nhỏ như điều chỉnh cách tính doanh thu thuần phải sửa ở nhiều file. Với semantic model dùng chung, bạn sửa một lần và mọi báo cáo kết nối vào đều cập nhật theo. Bạn cũng có thể đánh dấu mô hình là promoted hoặc certified để đồng nghiệp biết đâu là nguồn đã được kiểm duyệt, và dùng Analyze in Excel để người làm quen với PivotTable khai thác cùng một mô hình.
2. Phân quyền bằng RLS và quyền truy cập
RLS giúp bạn gửi một báo cáo cho nhiều người mà không phải tạo nhiều bản. Lưu ý khi kiểm thử: người có quyền chỉnh sửa trong workspace thường không bị RLS giới hạn, nên hãy dùng chức năng "View as" để thử từng role, và đối chiếu quy tắc áp dụng trên Microsoft Learn trước khi chia sẻ dữ liệu nhạy cảm.
3. Semantic model là nền cho Copilot và AI agent
Copilot và các AI agent (tác tử AI, chương trình dùng mô hình ngôn ngữ để thực hiện nhiều bước công việc) đều cần hiểu dữ liệu của bạn. Chúng không hiểu từ cột amt_net_v2, nhưng hiểu được measure Net Revenue có mô tả rõ ràng. Nói cách khác, mô hình càng sạch thì câu trả lời của AI càng ít sai lệch.
Một semantic model "AI-ready" thường có vài đặc điểm thiết thực:
Tên bảng, cột, measure viết theo ngôn ngữ nghiệp vụ, không dùng mã nội bộ.
Mỗi measure quan trọng có mô tả ngắn: tính gì, đơn vị nào, loại trừ gì.
Cột kỹ thuật (khoá, cột trung gian) được ẩn đi.
Quan hệ và bảng Date rõ ràng, để câu hỏi theo thời gian được trả lời đúng.
Đây cũng là chỗ nhiều người bỏ qua khi thử AI trên dữ liệu: họ trách mô hình AI trong khi lớp ngữ nghĩa chưa được làm cho rõ. Nếu bạn muốn đi tiếp từ nền này sang việc điều phối AI agent trong phân tích, Agentic AI Analytics Program của MDA đi theo hướng đó.
V. Semantic model khác gì dataset và data model trong Power BI Desktop?
Ba cụm từ này hay bị dùng lẫn. Bảng dưới đây phân biệt theo cách dùng trong công việc.
Khái niệm | Bản chất | Bạn gặp ở đâu | Ghi nhớ |
|---|---|---|---|
Semantic model | Đối tượng mô hình hoá đã publish, dùng chung được | Power BI Service, Fabric | Tên hiện hành của dataset |
Dataset | Tên cũ của cùng đối tượng trên | Tài liệu, API, script cũ | Khi gặp, hiểu là semantic model |
Data model | Phần bảng, quan hệ, measure bạn dựng trong file | Model view của Power BI Desktop | Khi publish, nó trở thành semantic model |
Tóm lại, dataset và semantic model là một thứ với hai tên gọi. Data model là phần bạn làm việc trong Desktop, và nó chỉ trở thành semantic model dùng chung sau khi bạn publish lên Service.
VI. Câu hỏi thường gặp
1. Semantic model và dataset có phải là một không?
Có. Semantic model là tên hiện hành của dataset trong Power BI. Khi đọc tài liệu hoặc code cũ có chữ dataset, bạn hiểu là semantic model.
2. Một semantic model có phục vụ nhiều báo cáo được không?
Được, và đây là cách dùng nên ưu tiên. Bạn tách semantic model ra một file riêng, publish, rồi các báo cáo khác kết nối vào đó.
3. Có cần Microsoft Fabric mới dùng semantic model không?
Không. Chế độ Import và DirectQuery dùng được mà không cần Fabric. Direct Lake thì gắn với Fabric.
4. Cần loại license nào để chia sẻ semantic model?
Điều này phụ thuộc vào cách tổ chức bạn cấp license và dung lượng. Bạn nên hỏi bộ phận quản trị Power BI và đối chiếu Microsoft Learn thay vì tự suy đoán.
5. RLS có áp dụng cho người chỉnh sửa trong workspace không?
Thường thì không, người có quyền chỉnh sửa có thể không bị giới hạn bởi RLS. Hãy kiểm thử bằng "View as" và đọc quy tắc trên Microsoft Learn trước khi chia sẻ.
6. Tôi có cần học DAX để làm semantic model không?
Có nền DAX sẽ giúp rất nhiều, nhất là khi viết measure. Bạn không cần biết hết, chỉ cần nắm CALCULATE, các hàm thời gian và DIVIDE là đủ cho hầu hết báo cáo bán hàng.
7. Làm sao biết semantic model của mình đã sẵn sàng cho Copilot?
Kiểm tra bốn điều: tên rõ nghĩa, measure có mô tả, cột kỹ thuật đã ẩn, quan hệ và bảng Date đúng. Sau đó hỏi thử vài câu quen thuộc và so với số bạn biết chắc.
VII. Kết luận
Semantic model là nơi bạn định nghĩa dữ liệu một lần để nhiều báo cáo và nhiều người cùng dùng. Nó gồm bảng, quan hệ, measure DAX, hierarchy và RLS, chạy ở chế độ Import, DirectQuery hoặc Direct Lake tuỳ nhu cầu. Dataset chỉ là tên cũ của cùng đối tượng đó.
Bước thử đầu tiên khá nhỏ: lấy một báo cáo bạn đang dùng, tách phần mô hình thành file riêng, publish lên workspace rồi cho một đồng nghiệp kết nối vào. Bạn sẽ thấy ngay chỗ nào trong mô hình cần đặt lại tên, thêm mô tả hoặc sửa quan hệ. Nếu muốn đọc thêm về Power BI và phân tích dữ liệu, bạn có thể xem Blog Mastering Data Analytics.
Lưu ý: phần dưới đây giới thiệu chương trình đào tạo của Mastering Data Analytics.
📚 Bắt đầu sự nghiệp Analytics vững vàng trong kỷ nguyên AI
Mastering Data Analytics (MDA) là một trong những đơn vị đào tạo phân tích dữ liệu tại Việt Nam, mang chương trình Agentic AI Analytics đến với người học. Sau hơn 6 năm đào tạo phân tích dữ liệu, MDA đã đồng hành cùng 3.000+ học viên và 250+ doanh nghiệp lớn như Heineken, Prudential, P&G, AEON, BIDV, Coca-Cola, Unilever. Điểm khác biệt của MDA không nằm ở những lời hứa kiểu '5 phút phân tích data với ChatGPT' hay 'vibe coding dashboard'. Chúng tôi rèn đúng bộ ba tạo nên lợi thế cạnh tranh thật sự thời AI: tư duy phân tích hệ thống, chuyên môn vững chắc và năng lực điều phối AI Agents.
Khám phá chương trình: Agentic AI Analytics, Finance Analytics
Tư vấn lộ trình miễn phí qua Zalo: 0961 48 66 48
Fanpage: Mastering Data Analytics
Nguồn tham khảo
[1] Leveraging Power BI for Enhanced Data Visualization and Business .... https://www.researchgate.net/publication/384342904_Leveraging_Power_BI_for_Enhanced_Data_Visualization_and_Business_Intelligence
Bình luận