Problem abstraction is the biggest advantage that OLAP applications have over other technologies such as relational reporting. What I mean by abstraction is that the terminology of the application is appropriate for the problem at hand. Abstraction lets business decision makers navigate data without the help of a data expert. When you use a relational-reporting tool to retrieve data, you deal with relational tables, columns, rows, joins between tables, foreign keys, and other basic concepts. These concepts are appropriate for a database designer, not a business analyst. When an analyst retrieves data in an OLAP application, the application presents data as concepts such as geographies, fiscal time periods, customers, product lines, and financial metrics. These are business concepts appropriate for solving business problems. Just think how ineffective an architect would be if she were forced to design a new building by thinking only in terms of boards, drywall, nails, bricks, and the like. An architect needs to describe the problem by using architectural concepts such as floors, walls, doorways, windows, and elevations.
The second concept that OLAP handles well is business logic—the rules for how you view data specific to your business or business segment. What metrics do you use to determine the health of your business or your functional department? Examples might be revenue per sales rep, revenue per head count, or if you're in retail, maybe sales per square foot of retail space. These metrics are what the BI industry calls key performance indicators (KPIs). A KPI is one type of business logic. Another type of business logic is selection or grouping. For example, how do you define your top customers? Is it by revenue, growth, profit, or perhaps some combination of the three? Selection logic encompasses the steps you perform to select items from your data that you want to treat as a group. The group could be problem products, risky customers, or second-tier customers. You define the names and the logic behind each group.
The business logic your company uses today is probably embedded in SQL statements that generate the reports you distribute to decision makers. So what happens when a decision maker needs a new report that uses the currently accepted definition of the top 10 customers? Typically, the DBA who's generating the report finds an old report that contains the 50 lines of SQL that define the top 10 customers, and she pastes that SQL fragment into the definition of the new report. If business logic isn't embedded in SQL, it's probably embedded in a few hundred Excel spreadsheets on decision makers' desktops.
At my company, we describe such a situation by using the term spreadsheet anarchy. Spreadsheet anarchy refers to the problem that arises when business logic is created and recreated hundreds of times on decision makers' desktops for analysis. Spreadsheet anarchy fights against the need to have a single version of the truth. How can you be sure that decisions are being made consistently throughout your organization if you don't know that everyone has the same definition of your key performance metrics or selection criteria (e.g., top customers)? Modern OLAP applications let you centrally define and reuse your business logic. You can imagine the benefits of having just one definition of top 10 customers and reusing that definition across multiple databases and analytic applications. Then, when the situation warrants it, you can change the definition of the top 10 customers in one location and be certain that all the uses of that logic have been updated.
The third area in which OLAP applications are different from relational-reporting applications is in addressing the discovery process of the human phase of decision making. OLAP provides three crucial ways to facilitate the discovery process: organization, visualization, and navigation. A user of an analytic application can organize, visualize, and navigate data in ways that let her quickly discover problems and find solutions.
OLAP addresses users' organization needs by presenting large amounts of data in multiple dimensions where each dimension is structured in one or more hierarchies. Users can focus on the dimensions (e.g., products, time, customers) that are most relevant to the problem at hand, then view each dimension at the appropriate level of summarization. For example, if I want to understand how a product's profitability changed over the past few months, I need to view only the time dimension (by months) and individual products. I exclude all other dimensions and dimension levels to eliminate any information that isn't relevant to what I want to understand—in other words, to shorten my discovery process.
Visualization is a primary differentiator between relational reporting and OLAP. Most relational reports are distributed as a grid of numbers. A good OLAP tool provides a full suite of business charts as well as other visualization tools so that you can present data in the most appropriate manner. For example, what's the best way to view your sales-force locations relative to the size and location of sales opportunities? It's a geographical map, not a grid of numbers. Of course, you can take the grid of numbers from your relational reporting tool and drop them into PowerPoint and create whatever visualization you want. But that kind of visualization is static, not dynamic.
OLAP is about navigation through lots of data. The assumption in an OLAP application is that no matter what data you're looking at, you'll always have more questions. You need to be able to select a piece of data from a chart or geographic map and drill down to view more details. Drilling down doesn't just mean the next layer of data in the dimension you're viewing; drilling down can mean getting more detail from another dimension. For example, if you're looking at the past four quarters, you might want to drill down and see the top customers in the third quarter. If you're viewing your data in a static PowerPoint slide, you can't explore.
I could discuss many more ways in which relational reporting and OLAP are different, but this article gives you some of the most important differences. Now, when someone tells you he's building an OLAP cube that uses a reporting tool to generate reports, you can tell him he's missing the point. Using an OLAP cube to generate traditional reports helps to optimize the data phase of the process—the same phase that relational reporting has been working on for the last 30 years. But OLAP goes beyond simple data delivery to facilitate the human phase of the decision-making process. Likewise, if someone says the new version of her relational-reporting tool has all the analytic features you'll ever need, ask her how well the tool addresses abstraction, centralized business logic, and the discovery process. Those areas are the design center for OLAP tools.
In most organizations, decision makers aren't interactively exploring data. They're either delegating the job or still relying on static reports about their business. So what does that mean for the future of OLAP? Remember that 10 years ago, most people had never used the Internet and had no idea what a search engine was. I assert that we're in the same situation with analytics today. In 10 years, most business people will be using analytics every day, and they'll have a tough time imagining how they performed their jobs effectively back in 2003.
I'm sure you can tell that I prefer OLAP applications to relational-reporting tools, but even I recognize that the world has a place for relational reporting. When a problem calls for delivery of small amounts of data to large numbers of users, no solution is more appropriate than relational reporting. But these days, problems that require small amounts of data are rare. I'd love to hear your opinions or experiences regarding the topic of relational versus OLAP, so please email me at olapmasters@sqlmag.com.
End of Article
Prev. page
1
[2]
next page -->
