Kimball Group puts out some fantastic design tips, and one I especially liked in the last year was one from Joy Mundy (Design Tip #158 Making Sense of the Semantic Layer). The arrival of this in my inbox was extremely timely because I was at the time involved in a disagreement with a BI consultant who was currently specialized in one of the new breed of BI tools. His position was that semantic layers were unnecessary and the realm of “traditional, IT-centric reporting environments.” If I didn’t understand that, well, I just didn’t understand the niche that particular product was fulfilling towards the goal of enabling ad-hoc end user reporting without IT involvement. The argument started because I was inquiring about the capability of third-party solutions like Kalido of preconfiguring the semantic layer for the tool rather than having to manually configure it.
The cynical side of me leans towards Upton Sinclair’s quote in this area: “It is difficult to get a man to understand something, when his salary depends upon his not understanding it.” In other words, if a BI tool doesn’t yet support the ability to automatically create a semantic layer, it is understandable the vendor takes the approach that a semantic layer isn’t needed—right up until the point they delivery that feature.
In this area, Joy didn’t mince words:
“Is the semantic layer a mandatory component of a DW/BI architecture? The answer is yes, if you plan to open the doors to your DW/BI system for ad hoc use. Every hour you spend on building a rich semantic layer will pay off in improved adoption and success in the user community. Don’t simply run the wizard for your BI tool and generate a semantic layer that’s equivalent to the underlying tables (even if they’re dimensional). Spend the time to make it as rational and polished as you can.”
Let me provide just a few quick examples of how I think this can be useful for any BI tool, even for the new breed of BI tools that pride themselves on not requiring semantic layers.