When it comes to Business Intelligence (BI) and Business Analytics (BA), you may have come across software which uses a semantic layer in order to run business reports.
But what is a semantic layer (and why is it important to business intelligence)?
At its core, a semantic layer is a way to represent data using regular business terms. Essentially it takes the information in the data store and translates them into terms that actually mean something to them.
A semantic layer is constructed by someone who understands both how data stores work, and how reporting needs to be done in the business. This person then creates a layer by naming the raw data fields into business-friendly terms, and hiding fields that aren’t needed.
This person can also create filters that might commonly be used, so that end users can run reports looking for the specific information they need, without having to know anything about the way the data storage is constructed.
So, for example, the person building the semantic layer might organize some data in terms of the year. They can then create a predefined filter for “This year”. When run, this would provide the data needed for the current year.
The semantic layer means that people accessing the data don’t see a collection of tables, but instead get a single list of expected business fields arranged into a folder structure. Then the users can run searches based on predefined conditions or queries, and access the results immediately. Typically, the software then allows a user to present the data in a way that is more impactful or useful for their reporting needs.
This is particularly helpful as it reduces the amount of time it takes for users to get the information they need, without having to continually seek assistance from the company’s developers. Without a semantic layer, a user would need to have prior knowledge about query languages, as well as an understanding of how the data store is structured. Instead, they can simply run reports as and when they need.
While business users might run their own ad hoc reports, it’s important to note that not everyone is going to be creating their own reports. In fact, you might find that those in your business expect the reports to be created for them.
However, the basic principle of the semantic layer still works – it is organized, and defined into set terms in a way that makes these queries much easier to run and the reports easier to produce.
It also means that information on how to access the data isn’t simply in the head of one developer – instead, it allows for your business to develop a common language, so that developers can understand and maintain reports that others might have made.
A semantic layer lets business analysts and developers work interactively with users, in order to prototype the kind of information that is needed. This is a great way to find out how information is being used and produced, and what works particularly well (or what doesn’t work.)
A semantic layer also creates uniformity in the way that queries are run. While for single reports this might not seem huge, when comparing reports it increases the accuracy and the consistency between the reports.
Best of all, it means that you can build up a history of reports that don’t need to depend on the data store. While this might not sound like such a big deal, it means that if you have to, you can make changes to the data store without having to make changes to individual reports. When you’re looking at hundreds of reports, it can simplify – and speed up – the process of the change, meaning that changing the design of your database won’t have a negative time cost to it.
Semantic layers are increasingly available within all types of report and are an excellent way to encourage cross-departmental collaboration, as well as highlighting data storage best practices.
The semantic layer is one of the key concepts in DashboardFox. We call it an App. By providing a semantic layer to translate the raw data into user-friendly terms and organization, DashboardFox allows non-technical business users to build reports and do complex visualizations, without writing any code.
You can learn more about the details of the App Building process in our help files here. But the concept is simple. Connect to your database, create a set of Report Categories that related to the common use cases of your data, bring in the database tables and views related to that table and build the relationships between them, and finally, add the fields you want to share with users in the Report Tree, named as they understand and organized in folders.
Once created, the DashboardFox App can be provided to users to build reports. Data-level security can be applied to limit the scope of what a user can build or view. And most importantly, the user doesn’t need any direct access to the database or knowledge of the database schema or SQL programming.
You can check out a recorded demo here, but we recommend you schedule a live demo with one of our technical experts (not a sales call). We can understand your requirements and show you how the self-service BI features of DashboardFox, combined with the no-subscription pricing model, may be the best fit for your team.