Short of spell-checking and proofreading, work on the "Advanced OLAP" chapter for my upcoming book on SQL Server 2005 (with co-authors Stephen Forte and Bill Zack) is done. This one chapter (which we may end splitting into two) covers an array of new features in Analysis Services 2005.
I believe very strongly that with this release of SQL Server, all Microsoft-centric developers should learn at least a little about OLAP. The biggest reason for this is that building cubes, building application functionality around them and keeping them up-to-date is now something that any good database administrator and/or developer can do.
It's time to step up. To explain why, let me just outline some common-sense principles that this release is based upon. They make the technology more accessible to you, and to the BI market in general:
- Keeping your cubes up-to-date shouldn't involve a lot of work. Proactive Caching, which in its basic form can be configured with a Wizard, can be used to maximize availability of your cube and currency of its data.
- You shouldn't need to be an OLAP expert to build simple cubes. It's not just that the tools used to build cubes are eaiser to use and more sophisticated, it's that the principles themselves are easier. Simple things are simple to do. Parent-child dimensions are easier, ordering of members in a dimension is easier, supporting multiple hierarchies is much more straightforward, etc.
- You shouldn't need to be an analyst or statician to use the cubes that get built. Built in visualization tools (KPIs) make cube data much easier to comprehend. Display folders allow for an immediate taxonomy of what can be an otherwise overwhelming list of dimensions and measures. And new perspectives make it simple to publish a subset of a cube and make it look like a separate cube to client applications.
- You shouldn't need high-level permissions on your database to build a cube on it. Analysis Services 2005 just needs your untransformed tables, views or stored procedures. Special queries stored in the AS database's Data Source View can help you transform the data if need be, and single tables can be used for multiple dimensions, so you don't need to create multiple views on the same table. You can even use your fact table as a dimension table.
- OLAP development should be more like other development. When you do go beyond simple cubes, and you need to write some server-side MDX code to make things work the way you want, you should have development and debugging support akin to what most developers are used to. Designing cubes inside Visual Studio makes this possible, and it's really cool!
- Learning MDX should be less necessary and less difficult. OLAP/MDX developers now have the same kind of drag and drop code generation and Intellisense support (albeit limited) that other devs do. They also have access to a huge library of templates for both server-side MDX expressions and client-side MDX queries. I'm all for coding into a blank page, but if used properly, tools and templates help you learn. MDX is a bear; that shouldn't be compounded with a velvet rope and a bunch of bouncers denying you entrance to the learning club and, thankfully, it no longer is.
- OLAP reporting should be easy. Check! Reporting Services' support for OLAP (and data mining) is strong, with an MDX query designer built right into the product. That same designer is now built into SQL Server Management Studio too, making Analysis Services a first class client inside SSMS, right alongside SQL's relational engine.
- There should still be cool stuff for the experts. Don't worry OLAP experts, your franchise has not been eradicated. There's a slew of features that you, and only you, can help customers realize the full value of. What this release does is lower barriers to entry, and most likely increase the market and demand for your expertise.
'Nuff said. If you want to learn more, you gotta wait for the book.