A Power BI Dataset — officially rebranded by Microsoft as a Semantic Model in 2023, though “dataset” remains widely used in documentation and conversation — is the hosted, in-memory analytical data model that powers Power BI reports. The dataset contains: the data itself (tables imported into VertiPaq, Power BI’s in-memory columnar storage engine, or connections to source data in DirectQuery mode), the relationships between tables, all DAX calculated columns and measures, row-level security role definitions, and data source connection credentials. A single dataset can serve as the data foundation for multiple reports — report designers connect to the published dataset in Power BI Service rather than building independent data models, enabling all connected reports to share the same data, the same metric definitions, and the same refresh schedule. The dataset is the central governance artifact of a Power BI deployment: the quality of its data model, the accuracy of its DAX measures, and the correctness of its RLS roles determine what every connected report shows and who can see it.
Dataset Architecture: Import vs DirectQuery vs Composite
| Mode | Data Storage | Query Performance | Data Currency | GCC Finance Use Case |
|---|---|---|---|---|
| Import | Data copied into VertiPaq in-memory store | Fastest — queries against in-memory cache | As of last refresh — scheduled refresh required | Management dashboards, monthly KPI packs |
| DirectQuery | No data stored — queries sent live to source | Depends on source system performance | Real-time — reflects source at query time | Live operational metrics, current-day cash position |
| Composite | Some tables imported, some DirectQuery | Optimised — frequently-queried aggregates imported; detail on demand | Hybrid — imported tables scheduled; DQ tables live | Historical trend imported + current period DQ |
The Dataset as the Single Source of Truth
The most significant governance benefit of the shared dataset model — where multiple reports connect to one published dataset rather than each building their own model — is metric consistency. When “Net Revenue” is defined once as a DAX measure in the dataset, every report that displays Net Revenue shows the same value, calculated by the same logic, against the same data. When the revenue calculation definition changes (a new product category is included, a returns adjustment methodology is updated), the change is made once in the dataset, and all connected reports automatically reflect the new definition at their next refresh. This single-point-of-definition architecture prevents the metric proliferation that is endemic in Power BI environments where each report developer builds their own model with their own Net Revenue interpretation.
GCC Enterprise Dataset Governance
For GCC enterprise finance environments where Power BI datasets are built on Oracle EBS, Oracle Fusion, or Oracle FCCS data, the dataset’s data model must handle several regional complexity requirements. Multi-currency reporting — where the same revenue figure must be available in SAR, USD, and AED — requires the dataset to store currency conversion tables and DAX measures that apply the appropriate rate based on the report’s currency filter context. Arabic-language dimension members — entity names and account descriptions in Arabic — must be stored as a parallel column in the dimension tables and surfaced through field parameters or report-level language switching, rather than requiring separate Arabic and English datasets. ZATCA-related VAT analysis — breaking down revenue by VAT treatment category — requires account classification columns in the dataset that are not available in a standard EBS GL extract and must be added through the transformation layer.
What Goes Wrong in Practice
The most common dataset design failure in production Power BI deployments is a dataset whose VertiPaq in-memory model is too large — because all historical transactional data was imported rather than only the summary data needed for reporting. A dataset that imports five years of daily GL journal line items to support a management dashboard that only ever displays monthly totals by entity is carrying 99% unnecessary data. Proper dataset scoping — importing only the grain and history required by the reporting use case — is the primary lever for keeping dataset size manageable, refresh times short, and Power BI Premium capacity costs controlled.
How Loop Wise Solutions Designs Datasets
We design Power BI datasets from the reporting requirements — specifying the required grain, history depth, dimension attributes, and measures before any data modelling begins. The dataset specification is reviewed and approved by the finance BI owner before the model is built, ensuring that the dataset serves the reporting use case rather than replicating the full data structure of the source system.
