The short answer is “yes.” The need to focus on business process measurement events, plus grain, dimensions and facts, is as important as ever.
When dimensional modeling was popularized several decades ago, we concentrated on schema designs that delivered query performance and ease-of-use. But as I described in Design Tip #160 Think Dimensionally (Beyond Data Modeling), focusing on business process events and metrics, along with the associated descriptive context, is useful in other situations including:
- Synthesizing business requirements (see Design Tip #3 Focus on Business Processes, Not Business Departments!)
- Defining and prioritizing manageable project scope (see The Bottom-Up Misnomer)
- Designing the overall DW/BI data architecture (see The Matrix: Revisited)
- Establishing data stewardship/governance responsibilities
- Presenting a business view of the organization’s information
“Thinking dimensionally” is vital, regardless of your underlying technology and data distribution strategies.
Meanwhile, technology has certainly advanced since dimensional models were introduced in the 1980s. Between NoSQL, virtualization and visualization technologies, some have predicted that the dimensional model must be on its deathbed. While some organizations are migrating some data to new platforms, relational and multidimensional solutions are far from obsolete. Dimensional schemas will continue in this space (and contrary to several big data pundits, they’ll continue to successfully handle atomic, granular data just as they have for decades.) Non-relational platforms are providing relational support. And dimensional models will help ensure consistent results from non-relational solutions.
Dimensional models organize data in a way that makes sense to business people, albeit potentially virtually. Some virtualization tools contend there’s no need to physically populate dimensional models. If your environment can deliver satisfactory query performance by accessing disparate data via a virtual logical dimensional model that provides the business view, perhaps you should give it a try. (I’d also recommend you conduct serious performance tests, evaluate the costs of ownership, think about the users’ requirements for slowly changing descriptive data, and so on.)
Some visualization tools contend there’s no need to dimensionalize because the tools prefer a flattened many-columned “big wide table.” In this case, the dimensional framework is beneficial for managing your data assets so consistent attribute-rich master dimension data is repeatedly attached to business process performance metrics rather than repeatedly embedding potentially inconsistent attributes in flattened data sets scattered around the organization. You should govern your dimension assets before presenting data per the visualization tool’s preferences. This will also help “future proof,” just in case the next great thing comes along with a new set of tool-specific requirements.
Finally, some dismiss the dimensional model as old news simply because it’s been a generally-accepted best practice for several decades. This one is hard to argue with. Yes, I’ve been doing dimensional modeling for over 30 years. Ralph Kimball’s original Data Warehouse Toolkit was published in 1996; I co-authored updated editions with him in 2002 and 2013. The concepts have withstood the test of time! Dimensional modeling has helped countless organizations across every industry make better business decisions which should be the true measure of DW/BI success. While it’s fun to try something new, why dismiss a proven, valuable technique that has provided positive return on investment?
Dimensional modeling doesn’t garner the vendor mindshare that big data and other technologies currently do, but that doesn’t mean it’s no longer relevant. There will most certainly be complementary roles in the DW/BI space for the foreseeable future.