This article is not relevant to versions of Elements before v5.19. Before this version, dashboards did not support use of the Reporting Database. They could only use the Analytics Database.

Dashboards do not source their data directly from the Elements operational database. Instead, they source their data from one or both of the secondary Elements databases specifically designed for use by Business Intelligence tools:

The Elements Reporting Database is a customisable traditional relational SQL database supporting direct SQL query access by your institution's data analysts, their BI tools such as Excel or Tableau, and much of the reporting functionality (including some dashboards) in Elements. It is updated continuously as changes are made to underlying data in the Elements operational database.
The Elements Analytics Database is a non-customisable OLAP database supporting direct MDX query access by your institution's data analysts, their BI tools, and some of the dashboards in Elements. It is updated nightly from data in the Reporting Database.

A wide selection of support articles dedicated to the Reporting Database are available in the following location. All of the tables and views in the reporting database are available for use in your dashboards.

Reporting Database Documentation

The dashboard design experience is slightly different for the two data sources. As a rule of thumb, you will almost always want to use the Reporting Database (SQL) for its wider range of data, its greater flexibility, and its lower latency, reserving use of the Analytics Database (OLAP) for dashboards where acceptable performance cannot otherwise be achieved.

A high-level comparison of features

The following table comparing the different high-level features and behaviours of the two databases might be of some use when deciding which database to use as the source of your dashboard.

	Reporting Database (SQL-based dashboards)	Analytics Database (OLAP-based dashboards)
Purpose and scope	The Reporting Database aims to provide access to all of the research data managed in Elements as a traditional relational database, supporting direct SQL access to over 300 tables of data by customers. This provides support for a very wide range of possible dashboards.	The Analytics Database is designed to demonstrate the performance and convenience improvements that can be achieved with an OLAP database over a traditional SQL database in the context of data analytics, by providing access to some of the data in Elements to OLAP BI tools. It also provides a platform supporting possible future options for high-performance stock dashboards that cannot be implemented by using the Reporting Database as their direct source of data. Compared to dashboards based on the Reporting Database, the Analytics Database supports a much smaller range of possible dashboards.
Performance	Dashboards using the Reporting Database execute SQL queries to aggregate and group its data in real-time. Although effective for small to medium-size datasets (number of queried rows) with low structural complexity (small number of SQL joins), SQL-based analysis can become sluggish for large or complex datasets, and can negatively affect the performance of the Elements system as a whole.	Dashboards using the Analytics Database execute MDX queries against data that has been extracted from the Reporting Database during the previous night and partially pre-aggregated and pre-grouped within the Analytics Database. Depending on the data being queried, this approach is capable of driving dashboards with orders of magnitude better performance.
Customisability	The Reporting Database is highly customisable, supporting addition of custom tables, views, stored procedures and indexes by your institution. All of these can be consumed by custom dashboards that use the Reporting Database as their source of data. Data in custom fields is automatically included in the Reporting Database (a Reporting Database rebuild may be required after changing field definitions in Elements).	The Analytics Database is not customisable. It presents a predetermined selection of measures and dimensions for consumption by OLAP-aware BI tools such as Excel, Tableau and the Elements dashboard designer. Data in custom fields is not propagated to the Analytics Database so cannot be analysed in any dashboard using it as its data source.
Latency	The bulk of data in the Reporting Database is kept up to date to within a few seconds of changes being made to the underlying data in the operational database. Some less frequently changing tables are synchronised only every hour, and tables with data that is expected to change very infrequently are refreshed only during a full Reporting Database reload, which can be triggered manually.	The Analytics Database is synchronised once every night, pulling its data from the Reporting Database. This means that dashboards using the Analytics Database as their source will not reflect changes in data that have occurred since the previous night.
Convenience	Use of data in the Reporting Database within dashboards requires the dashboard author to craft suitable SQL queries. Some degree of skill with SQL is therefore necessary. This provides for a slower, though ultimately more flexible and nuanced dashboard authoring experience.	Use of data in the Analytics Database within dashboards is very simple, with appropriate aggregations ("measures") and groupings ("dimensions") built-in to the database. This drives a simpler, though less flexible, dashboard authoring experience.

Dashboards: Choosing between the Reporting Database and the Analytics Database

A high-level comparison of features

Was this article helpful?

Thanks for the feedback!