A single dataset, AdWorksEnterprise, was utilized to support all reports and dashboards in each of the three dashboard architectures reviewed in the previous sections. This level of integration is not technically necessary and there are valid scenarios where multiple datasets could be used in the same Power BI solution and even by the same dashboard. However, additional or multiple datasets can quickly create problems due to separate data refresh processes, separate data source dependencies, and separate data security rules to implement.

Additionally, version control issues can arise as each dataset may include differences in the structure and definitions of tables common to both datasets. Moreover, the integration of visuals from the separate dataset on a dashboard may be insufficient to support analytical requirements.

In many cases, business users eventually need to analyze the data stored in separate datasets in the same report. For example, viewing dashboard tiles based on shipment and sales reports may be a helpful starting point but ultimately a user will need to filter both tables by product category, date, department, and other dimensions common to both business processes. A Power BI report is always limited to a single dataset as its source and thus an integrated dataset is always required whenever cross-analysis is required.

As one use case for multiple datasets, an organization may not have a particular data source, such as an Oracle database, integrated into its data warehouse system (for example, Teradata) but still wish to provide essential visualizations of this data in Power BI to supplement other reports and dashboards. In this scenario, a Power BI dataset could be built against the Oracle database, and reports utilizing this dedicated dataset could then support one or multiple dashboards. Once the necessary data warehouse integration was completed, the dedicated dataset could be retired and its reporting replaced with new reports based on an Analysis Services model (which uses Teradata as its source) that supports other Power BI reporting content for the organization.

The import versus DirectQuery dataset decision described earlier in this book significantly impacts the need for multiple datasets. For example, if the default import mode is used, a BI team could choose to load the separate data source (for example, Oracle) into the same dataset containing data from Teradata or another source. If a DirectQuery model was created, however, this model would be limited to its own source and database thus implying a separate dataset to support the Oracle database source.

In other scenarios, a dataset is chosen (or was already implemented) for one or a few business processes that aren't closely related to other business processes. For example, one dataset was built to include sales- and marketing-related data, while a separate dataset includes inventory and shipment data. The reasoning for this isolation may have been that the users of each dataset don't need access to the other dataset or that a large, integrated dataset would be complex to develop and use.

For example, it's not uncommon for datasets with multiple fact tables to require hundreds of DAX measures and Power BI Desktop currently doesn't support display folders or perspectives, such as Analysis Services, to help simplify the user interface. Additionally, if the Power BI Premium capacity is not available and Power BI datasets are used, the 1 GB file limit could force a team to utilize separate Power BI files to store the required data.

In general, corporate BI projects should limit the use of multiple datasets for the reasons described and the long-term value of a centralized data store. However, in environments lacking a data warehouse and other scalable resources, such as an Analysis Services instance or Power BI Premium capacity, multiple datasets can be considered as an option and potentially the only option to support one or multiple dashboards in the same Power BI solution.